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System, Method, and Computer Program Product 
For Providing User-Defined Customization in the 
Evaluation of Credit Worthiness 

Abstract 

A system, method, computer program product, and combinations thereof, 
mat allows for user-defined customization in the evaluation of credit worthiness 
of both consumer and business applications. The system includes a credit 
evaluation customization system that executes a request to evaluate credit 
worthiness, a customization database that stores both pre-defined and user- 
defined data that is used by the customization system, and a front end system that 
preferably provides a graphical user interface to both access the customization 
system and to customize the data stored in customization database. The method 
of the present invention involves customizing data and evaluating the credit 
worthiness of the application by executing a request while utilizing the 
customized data. 
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System, Method, and Computer Program Product 
For Providing User-Defined Customization in the 
Evaluation of Credit Worthiness 



Background of the Invention 



Field of the Invention 



The present invention relates generally to evaluating consumer and 
business creditworthiness, and more particularly to greatly facilitate and enhance 
users' ability to rapidly modify, customize, and fine tune the consumer and 
business credit worthiness evaluation process. 



RelatedArt 



Computer and software based credit evaluation and decisioning systems 
are one of the many elements that are reshaping today's loan industry. Using 
computer and software based systems to automate portions of the credit 
decisioning process has been occurring since the 1970's, and has grown 
increasingly move common over the past twenty years. While certain financial 
institutions may continue even today to decision certain categories of credit 
applications in a manual environment without the assistance of automated 
computerized tools, today's computerized software credit evaluation and 
decisioning systems are used widely by all but the smallest financial institutions, 
or other credit grantors, in industries such as credit card, auto lending, or home 
equity lending. Today's computer and software based credit evaluation and 
decisioning systems automate some portion of the processes associated with the 
workflow that the credit granting institution follows when it receives, evaluates, 
decisions, and records the ultimate outcome of credit applications. In addition to 
automation of the credit evaluation and decisioning workflow, the computer and 
software based credit evaluation and decisioning systems incorporate the business 
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logic utilized to evaluate and decision the application, and a database in which 
data elements utilized by the system during the credit evaluation and decisioning 

process are stored. 

Generally, the business logic in today's credit decisioning engines is very 
limited in terms of the extent to which users of the system can modify its 
functionality without needing to modify the software code underlying the system. 
This means that the system is limited to business logic initially incorporated in 
the system. When it was designed, or to new business logic that can only be 
implemented after the software code is modified. Both alternatives impose major 
limitations on the, credit grantor's ability to quickly modify or fine tune its credit 
evaluation and decisioning process to respond to changing market conditions, 
new competitive pressures, and/or new credit product introductions. 
Additionally, because in today's computer and software based credit evaluation 
and decisioning systems the credit decisioning engine typically is closely 
integrated with the work-flow and database components of the system, the credit 
decisioning engine generally cannot be modified without also requiring 
corresponding modifications to be made to a system's workflow and database. 

Credit granting institutions today are looking to credit decisioning engines 
to enhance competitiveness and the ability to quickly respond to changing market 
conditions through, among other things, improving loan volumes by increasing 
the percentage of credit applications that can be automatically decisioned (i.e., 
decisioned without human involvement in the decisioning process), facilitating 
more effective pricing strategies, improving credit risk through user-controlled 
lending criteria, expanding business through cross-product approval, and allowing 
the credit decisioning engine to be independent from, and capable of integration 
with, various different workflow systems and databases. Credit decision engines 
today are limited in the extent to which they can address these objectives to the 
extent that they are, among other things, limited by the table structure, and table 
access and hierarchy which has been hard coded into the system, and integrated 
as inextricable components from a credit evaluation and decisioning system's 
workflow and database. What is needed is a method and system which allows 
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users, without the necessity for changing a credit decisioning engine's software 
code, to be able to manipulate and combine data elements in ways that permit the 
users to build rules, tables and matrices that support new business strategies. 
What is also needed is a way for users to be able to utilize credit decisioning 
engines as distinct and independent software modules, so that they can be 
modified without necessarily requiring corresponding modifications in the 
workflow and database components of the credit evaluation and decisioning 
system, and so that the credit decisioning engines can be integrated with different 
workflow and database systems. 

Summary of the Invention 

The present invention is a system, method, computer program product, 
and combinations thereof, that allows for user-defined customization in the 
evaluation of credit worthiness of both consumer and business applications. 
The system for the evaluation of credit worthiness of the present invention 
includes a credit evaluation customization system that acts as an analysis engine, 
where the analysis engine executes a request in the evaluation of consumer and 
business credit worthiness. The system may also include a front end system that 
preferably provides a graphical user interface to the users of the present invention 
to access the customization system. In addition, a customization database stores 
both pre-defined and user-defined data that is used by the customization system 
in the evaluation of credit worthiness. This data is either passed in via the front 
end system, collected by the customization system, or derived by the 
customization system. The front end system also preferably provides to the users 
of the present invention a graphical user interface to customize the data stored in 
customization database. 

The method of the present invention preferably involves setting up a 
customization database, where the data stored in the database is used for 
evaluating the credit worthiness of an application; evaluating, with a 
customization system, the credit worthiness of the application by executing a 



CA 02312641 2000-06-23 



request; allowing users of the present invention to customize the database data 
through a front end system; and allowing the users to access the customization 
system through the front end system. 

Another embodiment of the present invention provides for allowing users 
to compare credit bureau scores to custom scores. 

A further embodiment of the present invention provides for a way of 
providing analytical capabilities that will facilitate cross selling of different 
products. 

Further features and advantages of the invention, as well as the structure 
and operation of various embodiments of the invention, are described in detail 
below with reference to the accompanying drawings. In the drawings, like 
reference numbers generally indicate identical, functionally similar, and/or 
structurally similar elements. The drawing in which an element first appears is 
indicated by the leftmost digits) in the corresponding reference number. 

Brief Description of the Figures 

The present invention will be described with reference to the 
accompanying drawings, wherein: 

FIG. 1 is a block diagram representing an operating environment 
according to an embodiment of the present invention; 

FIG. 2 is a block diagram of the functional modules of the present 
invention connected by a network according to an embodiment of the present 
invention; 

FIG. 3 is a block diagram of a computer system preferably used to 
implement the present invention; 

FIG. 4 illustrates the dynamic steps to establish communication between 
a client and a server executing an object-oriented program. For illustration 
purposes, FIG. 4 is broken into nine(9) figures including FIG. 4A, FIG. 4B, FIG. 
4C, FIG. 4D, FIG. 4E, FIG. 4F, FIG. 4G, FIG. 4H and FIG. 41; 
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F1G. 5 is a flowchart illustrating how selection sets are executed according 
to an embodiment of the present invention; 

FIG. 6 illustrates the various collections of data stored in a customization 
database according to an embodiment of the present invention; 
5 FIG. 7 illustrates the modules of the background modules according to an 

embodiment of the present invention; 

FIG. 8 illustrates the modules of the application processing modules 
according to an embodiment of the present invention; 

FIG. 9 illustrates an exemplary request flow that includes all of the 
10 features of the bureau module according to an embodiment of the present 

invention; 

FIG. 10 illustrates an exemplary request flow that includes all of the 
features of the score module according to an embodiment of the present 
invention; 

15 FIG. 1 1 illustrates an exemplary request flow that includes all of the 

features of the price module according to an embodiment of the present invention; 

FIG. 12 illustrates an exemplary request flow that includes all of the 
features of the policy module according to an embodiment of the present 
invention; 

20 FIG. 13 illustrates an exemplary request flow that includes all of the 

features of the product module according to an embodiment of the present 
invention; 

FIG. 14 illustrates the modules of the administration modules according 
to an embodiment of the present invention; 
25 FIG. 1 5 illustrates an exemplary administration GUI screen for allowing 

the user to administer the database according to an embodiment of the present 
invention; 

FIG. 1 6 illustrates an exemplary administration GUI screen displaying the 
records for a rule set table according to an embodiment of the present invention; 
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FIG. 17 illustrates an exemplary administration GUI screen displaying the 
records for a rule set list table according to an embodiment of the present 
invention; 

FIG. 18 illustratesan exemplary administration GUI screen displaying the 
records for a scorecard table according to an embodiment of the present 
invention; 

FIG. 19 illustrates an exemplary administration GUI screen displaying the 
recoids for a matrix table according to an embodiment of the present invention; 

FIG. 20 illustrates an exemplary expression builder GUI screen according 
to an embodiment of the present invention; 

FIG. 21 is an exemplary expression builder GUI screen illustrating 
subfiles and a syntax checker according to an embodiment of the present 
invention; 

FIG. 22 is an exemplary expression builder GUI screen illustrating the 
building elements of the operator folder according to an embodiment of the 

present invention; 

FIG. 23 is an exemplary expression builder GUI screen illustrating the 
building elements of the constants folder according to an embodiment of the 

present invention; 

FIG. 24 is an exemplary expression builder GUI screen illustrating the 
building elements of the functions folder according to an embodiment of the 

present invention; 

FIG. 25 is an exemplary expression builder GUI screen illustrating the 
building elements of the expression folder according to an embodiment of the 

present invention; 

FIG. 26 is an exemplary expression builder GUI screen illustrating the 
building elements of the characteristic folder according to an embodiment of the 

present invention; 

FIG. 27 illustrates an exemplary rule set builder GUI screen according to 

an embodiment of the present invention; 
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FIG. 28 illustrates an exemplary rule set list builder GUI screen according 
to an embodiment of the present invention; 

FIG. 29 illustrates an exemplary scorecard builder GUI screen according 
to an embodiment of the present invention; 

FIG. 30 is an exemplary scorecard builder GUI screen illustrating example 
attributes of a characteristic according to an embodiment of the present 
invention; 

FIG. 31 is an exemplary scorecard builder GUI screen illustrating the 
challenger input window according to an embodiment of the present invention; 

FIG. 32 is an exemplary scorecard builder GUI screen illustrating the 
usage input window according to an embodiment of the present invention; 

FIG. 33 illustrates an exemplary matrix builder GUI screen according to 
an embodiment of the present invention; and 

FIG. 34 illustrates an exemplary request builder GUI screen according to 
an embodiment of the present invention. 
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Detailed Description of the Preferred Embodiments 
I. Overview of The Present Invention 

If a user desires, based on its own present and anticipated future business 
requirements, to automatically evaluate the credit worthiness of an application, 
the present offers a way to customize such evaluations. More specifically, the 
present invention greatly facilitates and enhances the ability of users within a 
credit granting institution to rapidly modify, customize and fine tune the business 
logic embodied in computer and software based consumer and business credit 
evaluation and decisioning systems. This business logic typically incorporates 
some or all of the following five categories of functionality: (1) retrieving and 
analyzing a credit bureau report on a credit applicant from a credit data repository 
(e.g., Equifax, TransUnion or Experian), (2) scoring the credit bureau report by 
attributing a numerical value to it based on a scorecard utilized by the credit 
granting institution to predict all applicant's credit performance, (3) applying 
pricing criteria that determine the interest rate and term applicable to the credit 
application, (4) applying business and policy rules that guide the conditions under 
which a credit granting institution may approve or decline a credit application, 
and (5) applying rules and strategies that facilitate cross-selling of additional or 
alternative products to the product for which the application was originally 
submitted (e.g., an application submitted for an automobile loan may also return 
an option for an automobile lease, and/or include an offer for the applicant to 
open a credit card account). 

The business logic in a computer and software based credit evaluation and 
decisioning system relating to the five functional areas of credit bureau retrieval 
and analysis, scoring, pricing, policies, and product is typically referred to as a 
system's credit decisioning engine. The present invention thus contemplates a 
credit evaluation customization system 105, a front end system 110, and a 
customization database as shown in FIG. 1 and described in detail below. 
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//. Terminology 

Before further describing the present invention, the following terms used 
herein below are first defined. These definitions are provided for illustrative 
purposes only, and to aid the reader in understanding the invention. The 
definitions are not intended to be all-inclusive. 

Application - An initial statement of personal and financial information 
required to apply for a loan. An applicant can be either a consumer or a business. 

Credit Report - A report detailing the credit history of a prospective 
borrower that is used to help determine borrower credit worthiness. 

Lender - The bank, mortgage company, mortgage broker, or other credit 
grantor, offering the loan. A lender is a typical user of the present invention. 

Attribute (weight) - A numeric value, positive or negative, that is 

evaluated for a characteristic of a scorecard and added to an overall score. The 

following sample illustrates three attributes for a characteristic: 

Value from Characteristic Operator Parameter Ppiflts 

X < 1 o 

X <= 10 6 

X > 10 12 

Grade - An overall indicator of an application's credit worthiness. 

Decision Status - A status assigned to the application based on the grade. 
Valid decision statuses include Approve, Pending Approval, Pending, Pending 
Decline, and Decline. 

Loan to Value (LTV) - The ratio of the loan amount to the value of a 
property. For example, a loan of $200,000 on a property valued at $400,000 is 
at an LTV of 50%. 

Score - Value that measures the relative degree of risk an applicant 
represents to the lender. 

Scorecard - Forecasts an applicant's credit performance on actual credit 

data. 
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Rule - A calculation, database field, complex rule (combination of 
existing rules), or scorecard. A rule can return any data type, except for complex 
rules which return an indication of "pass" or "fail." 

Complex Rule - A rule created by combining existing rules. Each rule 
in the combination uses its own evaluation logic, creating a component. "AND" 
or "OR" must be assigned between each component. Components may be 
grouped using parenthesis. An example is: (Rulel = "ABC" AND Rule2 < 10) 
OR Rule3 in ( M X,Y,Z"). Allowable operators are: =, <, <=, >, >=. The result of 
a complex rule is an indication of "pass" or "fail." 

Rule Set - A collection of rules. Each rule in the rule set is evaluated 
against a parameter, returning a "pass" or "fail." 

Rule Set List - A collection of rule sets. 

Group - A collection of rule set lists. 

Selection Rules - A rule or rule set used to select valid features, rule sets, 
or rule set lists. 

Characteristic - Component of a scorecard, and its logic (interpretation 
of bureau or application data). A characteristic may return a positive number or 
a string. For example, the characteristic "Number of Bureau Trades" can return 
a number. The characteristic "Type of Bank Accounts" can return the strings 
"none," "checking," "savings," or "both." Other values returned by a 
characteristic may include: "no bureau," "no hit," "no inquiries," and "no trade 
line." Characteristics may be derived from bureau or application data, and may 
be provided by the present invention or designed by a user. 

Policy - Guidelines of a particular user (e.g., lender) that states its review 
and lending policies. An example of a particular user's lending policy may be 
"Definitely decline an application with a 45% Debt to Income Ratio." 

Product - Vehicle Loan, Vehicle Lease, Home Equity Loan, Credit Card, 

etc. 

Request - Both pre-defined by the present invention and customized by 
the user. A request lists the option features (of a module) and the order in which 
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to execute the features that will take part in the evaluation of the credit worthiness 
of an application* 

Program - Provides a way of organizing fixed rate sheets, variable rates, 
credit limits, and deposit amounts. 

///. System Architecture 



A. System Architecture Overview 

1 0 FIG. 1 is a block diagram representing an example operating environment 

of the present invention. It should be understood that the example operating 
environment in FIG. 1 is shown for illustrative purposes only and does not limit 
the invention. Other implementations of the operating environment described 
herein will be apparent to persons skilled in the relevant art(s) based on the 

IS teachings contained herein, and the invention is directed to such other 

implementations. Referring to FIG. 1, a credit evaluation customization system 
105, a front end system 1 10, a customization database 1 15, the global Internet 
1 20, credit bureaus 1 25, and dealerships 1 30 according to an embodiment of the 
present invention, are shown. 

20 An embodiment of the functional components of the present invention 

includes customization system 105, front end system 110, and database 115. 
Customization system 105 acts as an analysis engine for the present invention in 
the evaluation of consumer and business credit worthiness. Customization 
system 105 is connected to front end system 1 10. Front end system 110 may 

25 provide a graphical user interface (GUI) to users of customization system 105. 

Although the embodiment of the present invention shown in FIG. 1 illustrates 
customization system 105, front end system 1 10, and database 1 15 as separate 
functional components, several (or all) components may be combined as long as 
the functionality of each component still exists within the present invention as 

30 will be described below. 
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Data needed to perform all features of the present invention is either 
passed in via front end system 110, collected by customization system 105, or 
derived by customization system 105. Requests can be made by front end system 
1 1 0 to customization system 1 05 at any time as long as customization system 1 05 
has the data to process the request. Thus, the various functions provided by the 
present invention are not dependent on the source of the data. 

Front end system 1 10 may also operate as a Web server. A Web server 
provides the GUI to users of customization system 105 in the form of Web pages 
when access is made via the Internet 1 20. As is well-known in the relevant art(s), 
a Web server is a server process running at a Web site which sends out Web 
pages in response to Hypertext Transfer Protocol (HTTP) requests from remote 
browsers. An optional firewall (not shown) serves as the connection and 
separation between front end system 1 10 and the global Internet 120. Generally 
speaking, a firewall— which is well-known in the relevant art(s)— is a dedicated 
gateway machine with special security precaution software. It is typically used, 
for example, to service Internet 120 connections and dial-in lines, and protects a 
cluster of more loosely administered machines hidden behind it from an external 
invasion. 

Customization system 105 is also connected to database 115. Database 
1 15 stores collections of both predefined and user-defined data required by 
customization system 105. Both the functions of the engine of customization 
system 105 and the data stored in database 1 1 5 will be discussed in further detail 
below. 

The global Internet 120 includes a plurality of external workstations that, 
not only allow users of the Internet 120 to remotely access and use customization 
system 105, but also allows customization system 105 to access the external 
workstations. In essence, both credit bureaus 125 and dealerships 130 may use 
an external workstation to interact with customization system 105. 
Customization system 105 and front end system 1 10 may interact with credit 
bureaus 125 to receive actual credit data for both consumer and business 
applicants. Customization system 105 and front end system 110 may interact 
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with dealerships 130 to indicate whether or not a loan has been approved for a 
particular applicant. It is important to note that the present invention is not 
limited to interacting with credit bureaus 125 and dealerships 130. The present 
invention may also interact with realtor companies, and any other company that 
has an interest in obtaining loans for its customers. Also note that the present 
invention may communicate with credit bureaus 125, dealerships 130, and so 
forth, via communication methods other than the Internet 120 (via TCP/IP), 
including asynchronous dial up and asynchronous lease line. What is meant by 
asynchronous dial up, asynchronous lease line, and TCP/IP communication is 
explained next. 

The term asynchronous is usually used to describe communications in 
which data can be transmitted intermittently rather than in a steady stream. For 
example, a telephone conversation is asynchronous because both parties can talk 
whenever they like. If the communication were synchronous, each party would 
be required to wait a specified interval before speaking. Asynchronous dial up 
refers to connecting a device to a network via a modem and a public telephone 
network. Asynchronous dial up access is really just like a phone connection, 
except that the parties at the two ends are computer devices rather than people. 
Because asynchronous dial up access uses normal telephone lines, the quality of 
the connection is not always good and data rates are limited. 

An alternative way to connect two computers is through an asynchronous 
leased line, which is a permanent connection between two devices. Leased lines 
provide faster throughput and better quality connections, but they are also more 
expensive. 

TCP/IP is an acronym for Transmission Control Protocol/Internet 
Protocol, the suite of communications protocols used to connect hosts on the 
Internet 1 20. TCP/IP uses several protocols, the two main ones being TCP and 
IP. TCP/IP is built into the UNIX operating system and is used by the Internet 
120, making it the de facto standard for transmitting data over networks. Even 
network operating systems that have their own protocols, such as Netware, also 
support TCP/IP. 



CA 02312641 2000-06-23 



-14- 

FIG. 2 is a block diagram of the functional modules of customization 
system 1 05 preferably connected by a network according to an embodiment of the 
present invention. It should be understood that the particular customization 
system 105 in FIG. 2 is shown for illustrative purposes only and does not limit 
the invention. Other implementations for performing the functions described 
herein will be apparent to persons skilled in the relevant art(s) based on the 
teachings contained herein, and the invention is directed to such other 
implementations. As will be apparent to one skilled in the relevant art(s), all of 
the modules "inside" of customization system 105 are preferably connected and 
communicate via a communication medium such as a network 220. 

The topology of network 220 as shown in FIG. 2 is called a bus topology. 
In general, the topology of a network is the geometric arrangement of functions 
(i.e., computers) within the system. Other common types of network topologies 
include star and ring topologies. Although the present invention is illustrated in 
FIG. 2 as incorporating a bus topology, the present invention can equally be 
applied to other topologies. 

Customization system 105 includes application processing modules 205, 
administration modules 210, and background modules 215. Each module of 
application processing modules 205 can be operated independently of the other 
modules. Data needed by the present invention is either passed in via front end 
system 1 1 0, collected by customization system 1 05, or derived by customization 
system 105. Requests can be made by front end system 1 10 to customization 
system 105 at any time as long as customization system 105 has the data to 
process the request. Thus, the various functions provided by the present 
invention is not dependent on the source of the data. Connected to customization 
database 115 is background modules 215 and administration modules 210. 
Administration modules 210 is also connected to front end system 1 10. These 
modules are described for illustrative purposes. The invention is not limited to 
these modules. 

In an embodiment of the present invention, application processing 
modules 205 contains five (5) modules. Each module performs a unique set of 
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processing features that are configured based on specific business requirements 
defined by the user. Such processing features include, among other features, 
obtaining and evaluating credit bureau data for an application, determining a 
score for the application based partly on the credit bureau data, determining a 
grade for the application based on the score, determining possible term loans for 
the application based on the grade, reviewing the application based on specific 
lender policies, and determining multiple products that the application could 
qualify for. Each processing module operates in conjunction with front end 
system 110 to form a complete automated credit processing solution. The 
individual modules of application processing modules 20S will be described in 
detail below with reference to FIG. 8. 

In an embodiment of the present invention, administration modules 210 
contains five (5) modules. Each module performs a unique set of administrative 
features that are configured based on the specific business requirements defined 
by the user. Such administrative features include, among other features, an 
interface to front end system 1 10, an interface to database 1 IS, direct access to 
the various modules of customization system 105, and the ability for users to 
customize system 1 OS for their particular business needs. The individual modules 
of administration modules 210 will be described in detail below with reference 
to FIG. 14. 

In an embodiment of the present invention, background modules 21 5 
contains four (4) modules. Each module performs a unique set of background 
features including, among other features, the evaluation of unique circumstances, 
the calculation of mathematical formulas, the requests for data from database 1 1 5, 
and the ability to accept data in various formats, parse the data, and save the data 
in appropriate database tables. The individual modules of background modules 
215 will be described in detail below with reference to FIG. 7. 
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& Preferred Implementation of the Present Invention 

The present invention (i.e., customization system 105, front end system 
110, database 1 15, or any part thereof) may be implemented using hardware, 
software or a combination thereof and may be implemented in one or more 
computer systems or other processing systems. In fact, in one embodiment, the 
invention is directed toward one or more computer systems capable of carrying 
out the functionality described herein. An example of a computer system 300 is 
shown in FIG. 3. The computer system 300 includes one or more processors, 
such as processor 303. The processor 303 is connected to a communication bus 
302. Various software embodiments are described in terms of this exemplary 
computer system. After reading this description, it will be apparent to a person 
skilled in the relevant art how to implement the invention using other computer 
systems and/or computer architectures. 

Computer system 300 also includes a main memory 305, preferably 
random access memory (RAM), and may also include a secondary memory 3 1 0. 
The secondary memory 310 may include, for example, a hard disk drive 312 
and/or a removable storage drive 314, representing a floppy disk drive, a 
magnetic tape drive, an optical disk drive, etc. The removable storage drive 314 
reads from and/or writes to a removable storage unit 3 1 8 in a well known manner. 
Removable storage unit 3 1 8, represents a floppy disk, magnetic tape, optical disk, 
etc. which is read by and written to by removable storage drive 3 14. As will be 
appreciated, the removable storage unit 318 includes a computer usable storage 
medium having stored therein computer software and/or data. 

In alternative embodiments, secondary memory 310 may include other 
similar means for allowing computer programs or other instructions to be loaded 
into computer system 300. Such means may include, for example, a removable 
storage unit 322 and an interface 320. Examples of such may include a program 
cartridge and cartridge interface (such as that found in video game devices), a 
removable memory chip (such as an EPROM, or PROM) and associated socket, 
and other removable storage units 322 and interfaces 320 which allow software 
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and data to be transferred from the removable storage unit 322 to computer 
system 300. 

Computer system 300 may also include a communications interface 324. 
Communications interface 324 allows software and data to be transferred between 
5 computer system 300 and external devices. Examples of communications 

interface 324 may include a modem, a network interface (such as an Ethernet 
card), a communications port, a PCMCIA slot and card, etc. Software and data 
transferred via communications interface 324 are in the form of signals 328 which 
may be electronic, electromagnetic, optical or other signals capable of being 

10 received by communications interface 324. These signals 328 are provided to 

communications interface 324 via a communications path (i.e., channel) 326. 
This channel 326 carries signals 328 and may be implemented using wire or 
cable, fiber optics, a phone line, a cellular phone link, an RF link and other 
communications channels. 

15 In this document, the term "computer program product" refers to 

removable storage units 318, 322, and signals 328. These computer program 
products are means for providing software to computer system 300. The 
invention is directed to such computer program products. 

Computer programs (also called computer control logic) are stored in 

20 main memory 305, and/or secondary memory 310 and/or in computer program 

products. Computer programs may also be received via communications 
interface 324. Such computer programs, when executed, enable the computer 
system 300 to perform the features of the present invention as discussed herein. 
In particular, the computer programs, when executed, enable the processor 303 

25 to perform the features of the present invention. Accordingly, such computer 

programs represent controllers of computer system 300. 

In an embodiment where the invention is implemented using software, the 
software may be stored in a computer program product and loaded into computer 
system 3 00 using removable storage drive 3 1 4, hard drive 3 1 2 or communications 

*° interface 324. The control logic (software), when executed by processor 303, 
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causes processor 303 to perform the functions of the invention as described 
herein. 

In another embodiment, the invention is implemented primarily in 
hardware using, for example, hardware components such as application specific 
integrated circuits (ASICs). Implementation of the hardware state machine so as 
to perform the ftinctions described herein will be apparent to persons skilled in 
the relevant art(s). 

In yet another embodiment, the invention is implemented using a 
combination of both hardware and software. 

C A Preferred Software Programming Language and Network 
Architecture 

As discussed above, computer programs when executed, enable computer 
300 to perform the functions of the present invention as discussed herein. In a 
preferred embodiment, the present invention is implemented using computer 
programs written in an object-oriented programming language. Object-oriented 
programming is a type of programming in which programmers define not only the 
data type of a data structure, but also the types of operations (functions) that can 
be applied to the data structure. In this way, the data structure becomes an object 
that includes both data and functions. In addition, programmers can create 
relationships between one object and another. For example, objects can inherit 
characteristics from other objects. 

One of the principal advantages of object-oriented programming 
techniques over procedural programming techniques is that they enable 
programmers to create modules that do not need to be changed when a new type 
of object is added. A programmer can simply create a new object that inherits 
many of its features from existing objects. This makes object-oriented programs 
easier to modify. To perform object-oriented programming, one needs an 
object-oriented programming language (OOPL). C++ and Smalltalk are two of 
the more popular languages, and there are also object-oriented versions of Pascal. 
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While a preferred embodiment of the present invention is implemented 
using computer programs written in an object-oriented programming language, 
the present invention can also be implemented using procedural programming 
languages, etc. 

As discussed above, one or more of computers 300 is connected by a 
network. A preferred embodiment of the present invention uses a type of network 
architecture called a peer-to-peer object architecture. Before peer-to-peer object 
architecture can be understood, a type of network architecture called client/server 
architecture must be described. Client/server architecture is a network 
architecture in which each computer or process on the network is either a client 
or a server. Servers are computers or processes dedicated to managing disk drives 
(file servers), printers (print servers), applications/functions or network traffic 
(network servers ). In fact, a server is any computer or device that allocates 
resources for an application. Clients are personal computers or workstations on 
which users run applications. Clients rely on servers for resources, such as files, 
devices, execution of functions and even processing power. 

FIG. 4 illustrates the dynamic steps to establish communication that occur 
between a client and a server executing an object-oriented program. In FIG. 4A, 
the client has switchboard object 402 and listen object 404 waiting for a request 
from the server. In FIG. 4B, init object 406 determines that it needs to perform 
a specific task. In FIG. 4C, init object 406 creates coram object 408. Comm 
object 408 is used to communicate with the client. Then, coram object 408 makes 
a connection to listen object 404 in FIG. 4D. Once comm object 408 makes the 
connection, listen object 404 creates comm object 4 1 0 and relocates comm object 
410 to switchboard object 402. Comm object 410 is used to communicate back 
to the server (i.e., between the two piers), via comm object 408. 

At this point, as shown in FIG. 4F, there is two-way communication 
between the client and the server (i.e., between the two piers) through comm 
object 408 and coram object 410. Init object 406 knows which receiver object 
needs to be created by the client (i.e., receiving pier) to perform the specific task 
required. Therefore, once this communication is established, init object 406 
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sends a request to the client (i.e., receiving pier) to create the specific receiver 
object In FIG. 4G, switchboard object 402 receives the request, via comm object 
410, and creates receiver object 412. Once receiver object 412 is created, comm 
object 4 1 0 is relocated to receiver object 4 1 2 in FIG. 4H. Now, as shown in FIG. 
41, init object 406 and receiver object 412, via comm object 408 and comm object 
410, can communicate back and forth until receiver object 412 completes the task 
requested by init object 406. 

As stated above, a preferred embodiment of the present invention uses a 
type of network architecture called a peer-to-peer object architecture. A peer-to- 
peer object architecture is when each computer in the network has equivalent 
capabilities and responsibilities. This differs from client/server architectures, in 
which some computers are dedicated to serving the others. Therefore, in a 
preferred embodiment of the present invention, all modules (e.g., computers 300) 
can operate as either a server or a client with respect to all other modules. For 
example, application processing modules 20S has a score module that determines 
a score for the application based partly on credit bureau data. Background 
modules 21 5 has both an evaluator module and a calculator module. The 
evaluator module evaluates unique circumstances (e.g., set of rules), whereas the 
calculation module calculates mathematical formulas. A possible scenario of the 
present invention is that the score module may ask the evaluator module to 
execute a set of rules, which may request a calculation from the calculator 
module. In this scenario the evaluator module is a server to the score module and 
a client to the calculator module. 

As discussed above, one advantage of using an object-oriented 
programming language is that it allows programmers to create modules that do 
not need to be changed when a new type of object is added. In fact, each module 
of the present invention is a self-contained object that can exist, evolve, and 
execute without the presence of any other module. Each module exposes its 
services, which can be used by any other module. 

In a preferred embodiment of the present invention, the modules (and the 
features within) are built and packaged as Common Object Request Broker 
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Architecture (CORBA) compliant modules with CORBA Interface Definition 
Language (IDL) used for interface specifications between the modules. The IDL 
is used to define interfaces to objects. Remote objects view a CORBA object 
purely in terms of its interface. IDL provides encapsulation of an object's 
5 implementation behind a formal IDL interface that is independent of 

implementation language, implementation algorithm, location, machine 
architecture, operating system, and network technology. This separation of 
interface and implementation allows CORBA to be viewed as a 1 software bus,' 
and is one of the most powerful aspects of CORBA. 

10 In fact, when the modules of the present invention are built and packaged 

as CORBA compliant modules, network 220 (FIG. 2) is implemented as an object 
request broker (ORB). Here, network 220 is really an 'object bus* that handles 
all communication between application processing modules 20S, administration 
modules 210, and background modules 215. It is the implementation of the 

IS modules of the present invention as CORBA compliant modules that help to 

provide ease of customization to users. It is possible to provide variations of the 
features through multiple interfaces of the modules. To the extent possible, 
business functionality is separated from technical implementation. This 
separation provides future maintainability, ease of enhancements, and additions 

20 of new features. 

IK Rule Driven Functionality of the Present Invention 

Much of the functionality of the present invention is driven by rules. In 
order to have an understanding of the present invention, it is necessary to 
understand rules and how they are evaluated. As stated above, a rule is defined 
25 as a calculation, database field, complex rule (combination of existing rules) or 

a scorecard. A rule can return any data type, except for complex rules, which 
return an indication of "pass" or "fail." Rules may be validated individually, but 
more commonly in rule sets. Therefore, a rule set is a collection of rules where 
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each rule is evaluated against a parameter. A rule set list is a collection of rule 
sets, and a group is a collection of rule set lists. 

All rule sets are evaluated the same way, and have the same output 
(pass/fail). The present invention provides five different categories of rules/rule 
5 sets. The categories include pre-feature, selection, policy, scorecard, and 

calculation. An explanation of each of these rule categories is discussed next. 

/4, Pre-Feature Rule 

A pre-feature rule determines whether a module of the present invention 
should be run at all. As will be described later in reference to FIG. 8, application 

10 processing modules 20S include five modules. The five modules include a 

bureau module, a score module, a price module, a policy module, and a product 
module. An example of a pre-feature rule is a pre-bureau rule that determines 
whether the bureau module should be executed. One example of a pre-bureau 
rule may be to execute the bureau module only if the applicant's age is 18 or 

15 older. A pre- pricing rule determines if the price module is required for the 

particular application. Although the standard output for a rule is available, the 
only thing that is required of a pre-feature rule is an indication of N pass" or "fail." 

A scorecard may be used as a rule in a pre-feature rule set. In that way a 
"pre-bureau" scorecard can be run, and the value that it returns can be evaluated 

20 against a parameter to determine if the bureau module should be executed. Pre- 

feature rules will be described below in more detail in Section VI. 

A Selection Rule 

Selection is used within a module for selection of valid rule sets, rule set 
25 lists, scorecards, and so forth. Although the standard output for a rule is 

available, the only output that is required of a selection rule is the ID of what it 
is selecting. A rule within a selection rule set can be a scorecard. In this way 
users can use the results of a pre-score scorecard to determine which decision 
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scorecard to use. FIG. 5 is a flowchart illustrating how selection rules work. 
Note that if no rule set passes all of its rules, then no ID is chosen. Here, the use 
of a default rule set can assure that an ID is always selected. 

The flowchart in FIG. 5 illustrates how selection sets work for selection 
of a valid rule set. Note that each rule set has an ID attached to it. The flowchart 
begins at step 505 with control immediately passing to step 510. 

In step 5 10, input is received that indicates whether the selection rule is 
to be used within the particular module for selection of valid rule sets, rule set 
lists, scorecards, and so forth. Control then passes to step 515. 

In step 5 1 5, the first rule set in the selection list is retrieved from database 
115. Control then passes to step 520. 

In step 520, the first rule in the selectionrule set is retrieved from database 
115. Controlthenpassestostep525. 

In step 525, the rule is tested. Control then passes to step 530. 
In step 530, it is determined whether the rule was the last rule in the rule 
set If the rule was not the last rule, then control passes to step 535. If the rule 
was the last rule, then control passes to step 540. 

In step 535, the next rule in the selection rule set is retrieved and control 

returns to step 525. 

In step 540, it is determined whether all rules in the rule set have been 
passed. If all rules have not been passed, then control passes to step 545. If all 
rules have been passed, then control passes to step 555. 

In step 555, the ID to the rule set is written to database 1 1 5 and control 
transfers to step 565, where the flowchart in FIG. 5 ends. 

In step 545, it is determined whether the rule set was the last rule set in the 
list. If the rule set was not the last rule set in the list, then control transfers to step 
550. If the rule set was the last rule set in the list, then control transfers to 
step 560. 

In step 550, the next rule set in the selection list is retrieved and control 
returns to step 520. 
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In step 560, the default ID is written to database 115. Here, no rule set in 
the selection rule list had all of its rules passed. Control then transfers to step 
565, where the flowchart in FIG. 5 ends. 

C Policy Rule 

Review (above and below) and lending rules fall into this category. In 
general, a review above rule is used by the present invention to prevent automatic 
approval of an application and to alert an analyst about problem areas in an 
application. A typical review above rule is "look closely at an application with 
a 42% Debt to Income Ratio." A review below rule is used to prevent automatic 
declines of an application and to alert an analyst about circumstances in an 
application that warrant a closer look. A typical review below rule is "look 
closely at an application where the applicant make over $100,000 per month." 
A lending rule of the present invention is used to prevent users from approving 
loans that are outside of the company's guidelines. A typical lending rule is 
"definitely decline an application with a 45% Debt to Income Ratio." 

D. Scorecard Rule 

Scorecard characteristics are another example of a rule. They can be 
database fields, calculations, or complex rules. They are evaluated in the same 
way as all rules, although one characteristic may return multiple data types. The 
results will be further processed to assign attributes (e.g., weights, points). 

EL Calculation Rule 

This category of rule contains only calculations, the results of which may 
be saved in database 115 for use later on. One application may have multiple 
calculation rules and/or rule sets to be evaluated. For example, front end system 
1 1 0 may request that LTV and net down payment calculations are done before a 
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bureau is called. Typically when LTV is too high the application is automatically 
declined. 

V. Customization Database 

In general, a database is a collection of information organized in such a 
way that a computer program can quickly select desired pieces of data A 
database is similar to an electronic filing system. To access information from a 
database, you need a database management system (DBMS). This is a collection 
of programs that enables you to enter, modify, organize, and select data in a 
database. 

Traditional databases are organized by tables, fields, records, and files. 
A field is a single piece of information; a record is one complete set of fields; a 
table is a collection of records; and a file is a collection of tables. For example, 
a telephone book is analogous to a file. It contains a list of records, each of which 
consists of three fields: name, address, and telephone number. 

An alternative concept in database design is known as Hypertext. In a 
Hypertext database, any object, whether it be a piece of text, a picture, or a film, 
can be linked to any other object. Hypertext databases are particularly useful for 
organizing large amounts of disparate information, but they are not designed for 
numerical analysis. 

The present invention may also be implemented using a standard database 
access method called Open DataBase Connectivity (ODBC). The goal of ODBC 
is to make it possible to access any data from any application, regardless of which 
DBMS is handling the data. ODBC manages this by inserting a middle layer, 
called a database driver, between an application and the DBMS. The purpose of 
this layer is to translate the application's data queries into commands that the 
DBMS understands. For this to work, both the application and the DBMS must 
be ODBC-compliant - that is, the application must be capable of issuing ODBC 
commands and the DBMS must be capable of responding to them. The various 
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collections of data stored in database 1 15 are discussed next with reference to 
FIG. 6. 

In FIG. 6, database 1 1 5 (FIG. 1 ) stores collections of pre- feature rules 603, 
scorecards 605, selection rules 610, calculation rules 615, policy rules 620 
(including review and lending rules), matrix data 625, user related data 630, 
historical data 635, bureau setup tables 640, and so forth. It should be 
understood that the example collections of data shown in FIG. 6 is for illustrative 
purposes only and does not limit the invention. Other collections of data stored 
in database 1 15 described herein will be apparent to persons skilled in the 
relevant art(s) based on the teachings contained herein, and the invention is 
directed to such other collections of data. Such collections of data not illustrated 
in FIG. 6 that may also be stored in database 1 15 include, but are not limited to, 
unique IDs for each item of data, characteristics, and so forth. 

Pre-feature rules 603, scorecards 605, selection rules 610, calculation 
rules 615, and policy rules 620 were introduced above. Matrix data 625 includes 
data stored in the form of a two-dimensional array; that is, an array of rows and 
columns. It is important to note that the present invention is not limited to 
matrices in the form of two-dimensional arrays. In fact, the present invention 
contemplates matrices with any number of dimensions. In fact, this could 
happen when one matrix references another matrix. Matrix data 625 can be 
both customized by the user and pre-defined by the present invention. Matrix 
data 625 is used by the present invention to compare one type of data to 
another. An example of this is to compare credit bureau scores to custom 
scores to receive a grade for a particular application. Table 1 illustrates an 
example of matrix data 625. 
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Tablel 
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The grades indicated in Table 1 are Al, A2, A3, and so forth. Al 
indicates that the applicant has the strongest credit worthiness, while C3 indicates 
the weakest credit worthiness. 

User related data 630 relates to current credit evaluation results for each 
application submitted to a credit bureau. Historical data 63S relates to historical 
credit evaluation results for applications submitted to a credit bureau at an earlier 
time. Storing both types of credit evaluation results allows the user to request a 
comparison of an applicant's current and historical credit evaluation results. 

Bureau setup tables 640 contain data needed to call and process bureau 
information. This information includes, but is not limited to, the name, address, 
city, state, zip code, reference phone number, password, and access phone number 
for each bureau that can be called. 

VI. General System Operation 

The manner in which users may navigate through the functional modules 
and features provided by customization system 105 will now be described. 
Customization system 1 05 provides GUI front end system 1 1 0 so that it may be 
accessible and customizable by a user directly on a desktop computer, via a 
World Wide Web page over the Internet (i.e., through on-line services), or 
accessible via an Intranet. In an alternative embodiment, it may be accessible via 
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telephone services or the like. It should be understood that the control flows 
described are for example purposes only. Front end system 1 10 of the present 
invention is sufficiently flexible and configurable such that users may navigate 
through customization system 1 05 in ways other than that described. 

Referring again to FIG. 2, customization system 1 05 includes application 
processing modules 205, administration modules 210, and background modules 
215. Eachofmodule 205, 210, and 215 contains multiple modules. Eachmodule 
of application processing modules 205 performs a unique set of processing 
features that are configured based on specific business requirements defined by 
the user. Each module of administration modules 210 performs a unique set of 
administrative features that are also based on the specific business requirements, 
also defined by the user. Each module of background modules 215 performs a 
unique set of background functions required by both application processing 
modules 205 and administration modules 210. Because the modules in 
background module 21 5 are called upon by both application processing modules 
205 and administration modules 210, the modules in background modules 205 
will be described first. Next, application processing modules 205 will be 
described. Finally, administration modules 2 1 0 will be described. 

A . Background Modules 

Each module of background modules 215 performs a unique set of 
background functions required by both application processing modules 205 and 
administration modules 210. Referring to FIG. 7, background modules 215 
provides an evaluator module 705, a calculator module 710, a data manager 
module 715, and an external data parser module 720. Each of these modules is 
described in detail below. 
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L Evaluator Module 

As stated above, much of the functionality of the present invention is 
driven by rules. It is evaluator module 705 that is called upon by the other 
modules of the present invention to evaluate rules and/or rule sets. Again, the 
5 five different categories of rules/rule sets include pre-feature, selection, policy, 

score card, and calculation. 

For each rule processed by evaluator module 705 the following may be 
returned: (I) Rule ID - the unique identifier for the rule; (2) Rule Description - 
a description of the rule; (3) Application Value - the value returned for this rule; 

1 0 (4) Rule Parameter - the parameter that the particular application is being tested 

against to determine a "pass" or "fail;" (5) Identity of Applicant - if rules are 
applicant specific, then return the identity of the applicant used in the test; (6) 
Pass/Fail - whether the rule passed or failed; and (7) Miscellaneous Code - this 
varies by the type of rule being evaluated. For example, for a review rule type of 

1 5 policy rules 620, the code may be an adverse action reason code. For a policy 

rule type of policy rules 620, the code may be a lender level code. 

For each rule set processed by evaluator module 705 the following may 
be returned: (1 ) Rule Set ID - the unique identifier for the rule set; (2) Rule Set 
Description - a description of the rule set; (3) Pass/Fail - whether the rule set 

20 passed or failed (note that the failure of any rule within the rule set triggers a 

"fail" for the entire rule set); and (4) Miscellaneous Code - this varies by the type 
of rule set being evaluated. For example, for a selection rule set, the code may 
be the ID of a scorecard 605, matrix data 625, program, and so forth. 

2. Calculator Module 



25 



Calculator module 71 0 is called upon by evaluator module 705 to process 
any mathematical calculations that are required. Calculator module 710 will 
compute such things as LTV, debt to income ratio, payment to income ratio, 
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credit limit, deposit amount, and so forth. The present invention includes an 
extensive library of calculation rules 615. 

J. Data Manager Module 

Data manager module 7 15 handles all requests for data from database 1 15. 
5 Data manager module 7 1 S acts as an intermediary between database 115 and the 

other modules of the present invention. One exception to this is shown in FIG. 
2 where administration modules 210 may directly access database 1 15. 

* External Data Parser Module 

As stated above, data needed to perform all modules/features of the 
10 present invention is either passed in via front end system 110, collected by 

customization system 105, or derived by customization system 1 05. Therefore, 
the present invention must be able to accept and/or process data in various 
formats. Two types of data formats are fixed length and comma delimited. It is 
external data parser module 720 that allows the present invention to accept data 
1 5 in various formats, parse the data, and then save the data in the appropriate table 

in database 1 1 5 (via data manager module 7 1 5). 

A bureau OUT file is a credit data file received from a particular bureau 
in response to a request for the evaluation of a credit application. Therefore, it is 
likely that different bureaus have different OUT file formats. The primary 
20 function of external data parser module 720 is to allow different bureau OUT file 

formats to be defined in the present invention, and updated without changing 
code. External data parser module 720 is also useful for processing credit 
application files itself. 

In an embodiment of the present invention, the definition of a particular 
25 file format will be table driven. The goal is to allow electronic interfaces without 

having to write code. External data parser module 720 is able to handle both 
fixed length or delimited files. Following, in Table 2, is an example of a table 
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used by externa) data parser module 720 for reading fixed length bureau OUT 
files. 



Table 2 
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Table 3 is an example of a table used by external data parser module 720 
for reading fixed length credit application files. 
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Table 4 is an example of a table used by external data parser module 720 
for reading comma delimited credit application files. 



Table 4 
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B. Application Processing Modules 

Each module of application processing modules 20S performs a unique 
set of processing features that are configured based on specific business 
requirements defined by the user. Referring to FIG. 8, application processing 
modules 205 provides a bureau module 805, a score module 810, a price module 
8 1 5, a policy module 820, and a product module 825. Each module in processing 
modules 205 includes various optional features to execute. The features are 
optional because the user may decide to execute all or none, or any combination, 
of the features. These modules and features are described for illustrative 
purposes. The invention is not limited to these modules and features. 

/. Bureau Module 

The present invention may call credit bureaus 125, or credit bureaus data 
can be handed to the present invention for evaluation and summarization. The 
present invention supports at least the three major consumer bureaus 125, 
including Experian, TransUnion, and Equifax. In addition, at least two business 
bureaus 125 including Dun and Bradstreet and Experian Business are supported 
by the invention. The invention communicates with bureaus 125 with a variety 
of methods including both on-line and batch mode. As explained above, bureau 
module 805 may communicate with credit bureaus 1 25 via asynchronous dial up, 
asynchronous lease line, and TCP/IP (via the Internet 120). 

Referring to FIG. 9, the flow of an exemplary request that includes all of 
the features of bureau module 805 is shown. It is important to note that the 
present invention provides flexibility to the user in that the user may create a 
request that includes any number of these features and in any order that logically 
makes sense. How the present invention allows the user to create a request (via 
a GUI) will be described in detail below in Section VII. 

The flowchart in FIG. 9 begins at step 905 with control passing 
immediately to step 910. In step 910, the pre-bureau feature is executed. The 
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pre-bureau feature determines whether bureau module 805 should run based on 
user-defined criteria. A rule set is identified by front end system 1 10 or is chosen 
based on selection rule sets as valid for the application. Each rule in the rule set 
is evaluated by e valuator module 705. If any rale fails, bureau 125 is not called. 
A common pre-bureau rule would be "Applicant Age >= 18." Here, if the 
applicant is less than 18 bureau 125 does not get called. The output of the pre- 
bureau feature is "yes" or "no." Control then passes to step 915. 

In step 9 1 5, the bureau profile selection feature is executed. The bureau 
profile selection feature utilizes bureau set-up tables 640 stored in database 115. 
Bureau set-up tables 640 contain data needed to call and process bureau 
information. The valid bureau profile ID may be passed in by front end system 
1 1 0. If the valid bureau profile ID is not passed in by front end system 1 1 0, a list 
of rule sets will be evaluated by evaluator module 705 via selection rules. Each 
rule set will have a bureau profile ID attached to it. The ID attached to the first 
rule set that returns "Passed all Rules" becomes the selected (or valid) bureau 
profile ID. The output of the bureau profile selection feature is the bureau profile 
ID. Control then passes to step 920. 

In step 920, the bureau setup feature is executed. As stated above, bureau 
set-up tables 640 are stored in database 115. The tables 640 contain data that 
guide the rest of the features of bureau module 805. The bureau profile 
(indicated by the bureau profile ID obtained from the bureau profile selection 
feature in preceding step 915) indicates to the present invention which of the 
bureau set-up tables 640 are to be referenced for the particular application* Based 
on tables 640 referenced in the bureau profile feature, the bureau setup feature can 
be completed. The output of the bureau setup feature includes: (1) which 
bureau(s) to call; (2) under which circumstances a second (or third) bureau is to 
be called; (3) the name address, city, state, zip code, reference phone number, 
password, and access phone numbers for each bureau to be called; (4) whether 
bureau copies are allowed and for how many days; (5) whether each bureau 125 
should be called for all applicants, primary applicants only, co-applicants only, 
and so forth; (6) which add on' s are to be requested (score models, member phone 
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and address, fraud, GEO Code, etc.); (7) whether the debugger is on or off; (8) 
whether to save statistical data; and (9) whether to save the OUT file. Control 
then passes to step 925. 

In step 925, the bureau copy feature is executed. Here, based on if the 
bureau setup feature indicates that bureau copies are allowed, a bureau record is 
made available to copy. Bureau records can then be copied from one application 
to another. A bureau record is considered valid to copy for a particular applicant 
if it has the same social security number, and was retrieved within a specified 
time frame (determined by the bureau setup feature). The bureau copy feature 
works for any application, whether the applicant is a consumer or a business. 
The output of the bureau copy feature is a copy of the bureau records. Control 
then passes to step 930. 

In step 930, the bureau call feature is executed. The bureau call feature 
manages the communication with bureau(s) 1 25, based on data determined in the 
bureau setup feature. The goal of the communication is to send a request for a 
credit evaluation of an application. The management includes placing the request 
in a queue, accomplishing the actual communication with bureau 125, and the 
retrieval of the OUT file from bureau 125. The output of the bureau call feature 
includes: ( 1 ) the OUT file from bureau 1 25; and (2) statistical data related to the 
call itself. The statistical data includes the name of bureau 125 called, the device 
used to call bureau 125, the date of the call, the time of the call, the length of 
transmission for the call, the hit trades, the inquires, and any public records. 
Control then passes to step 935. 

In step 935, the parse OUT file feature is executed. The parse OUT file 
feature reads the OUT file and breaks its segments into fields via external data 
parser module 720. The fields can be used by the present invention for analysis 
and formatting of a TTY report. A TTY report is similar to a traditional report 
that might be faxed by a bureau to a lender if there were no computer to computer 
communications. The output of the parse OUT file feature is fields derived from 
OUT file segments. Control then passes to step 940. 
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In step 940, the feature that saves data from the OUT file is executed. 
This feature saves the fields derived from the OUT file segments in database 115. 
The fields can be either provided to the feature by front end system 1 10 or may 
be provided by the parse OUT file feature (explained above). Control then passes 
to step 945. 

In step 945, the feature that saves trades, inquiries, and public records data 
is executed. Here, based on the fields derived from the OUT file segments and 
saved in database 115, records can be entered in database 115 regarding trades, 
inquires and public records (via data manager module 715). Some summary data 
may also be saved. The rules of the present invention may depend on this 
information. It is important to note that saving these records requires some 
interpretation of the bureau data, but is independent of any bureau interpretation 
done for specific scorecard characteristics. The output of this feature is entries 
in database 1 15 for summary, trades, inquires and public records. Control then 
transfers to step 950. 

In step 950, the feature that formats a TTY report is executed. As 
mentioned above, a TTY report is similar to a traditional report that might be 
faxed by bureau 125 to a lender if there were no computer to computer 
communications. Many times users are most comfortable with this format when 
very detailed analysis is required. Based on the bureau data saved in database 
1 1 5, a standard TTY report (for the bureau) can be recreated and saved by this 
feature. The output of this feature is a text file that mimics a bureau TTY report. 
Control then passes to step 955, where the flowchart in FIG. 9 ends. 

There are three possible interfaces between the present invention and 
credit bureaus 125. The first interface involves bureau module 805 directly 
calling bureau 125. The second interface involves front end system 110 calling 
bureau 125 and then handing the OUT file to bureau module 805. The final 
interface involves front end system 1 1 0 calling bureau 125, parsing the segments 
into records (via external data parser module 720), and then handing the record 
data to bureau module 1 1 0 for storage in database 1 1 5 (via data manger module 
715). 
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Example of Possible Bureau Module Requests 

The present invention provides flexibility to the user in that the user may 
create a request that includes any number of these features and in any order that 
logically makes sense. For example, if a user is not interested in saving a bureau 
copy for the particular application, then the user would not include the bureau 
copy feature in his or her request. Following in Table 5 is each possible feature 
of bureau module 805, including a unique ID, name, and output for each feature. 



10 



15 




Bui 



Bu2 



Bu3 



Bu4 



BuS 



Bu6 



Bu7 



Bu8 



Bu9 



Table 5 



Prc-Bureau 



Bureau Profile Selection 



Bureau Setup 



Bureau Copy 



Bureau Call 



Parse OUT File 



Save Data From OUT File 



Save Trades, Inquiries, Public 
Records, and Summary Data 



Format TTY Report 



Yes or No 



Bureau Profile ID 



Which bureau(s) to call; Circumstances 
under which more than one bureau 
should be called; Name, address, etc. of 
bureau; Whether bureau copies are 
allowed and for how many days; Which 
applicants to call; Which Add On's to 
request; Whether debugger is on or off; 
Whether to save statistical data; 
Whether to save OUT file. 



Copy of bureau records. 



OUT file and statistical data related to 
call. 



Fields derived from OUT file. 



Entries in database of fields derived 
from OUT file. 



Entries in database of Trades, Inquiries, 
Public Records, and Summary Data. 



Text file that mimics the TTY report. 



20 



The purpose for Table 5 is to illustrate possible bureau module 805 
requests shown in Table 6. Table 6 includes a unique number for the request, 
what is passed in by front end system 1 10 and supplied by other modules to 
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bureau module 805, and the request itself (the listing of the bureau module 805 
features to execute). The requests shown in Table 6 may be both defined by the 
present invention and/or defined by the user. It is important to note that the 
present invention is not limited to the requests shown in Table 6. 



Table 6 



ilM'f k r?| him 








Bureau! 


Application Data 


Bui - 


Bu9 


Bureau! 


Application Data, OUT File 


Bu6- 


Bu9 


Bureau3 


Application Data, parsed OUT File 


!Su7- 


Bu9 



Referring to Table 6 and the Bureau 1 request, only the application data 
is passed to bureau module 805. Therefore, bureau module 805 must directly 
interface with bureau 125. Here, the request involves executing features Bui 
through Bu9. 

With the Bureau2 request, both the application data and the OUT file are 
passed to bureau module 805, Here, front end system 1 1 0 calls bureau 1 25 and 
then hands the OUT file to bureau module 805. Because bureau module 805 is 
not required to directly interface with bureau 125 itself, there is no need for 
features Bui through Bu5 to be executed. Therefore, the request involves 
executing features Bu6 through Bu9 only. 

Finally, with the Bureau3 request, the application data and the parsed 
OUT file are passed to bureau module 805. Here, front end system 1 10 calls 
bureau 125, parses the segments into records (via external data parser module 
720), and then provides the parsed record data to bureau module 1 10. This 
request involves executing features Bu7 through Bu9 only. 

2. Score Module 

Score module 8 10 of the present invention evaluates credit applications 
using scorecards 605 (FIG. 6) and then provides a decision. Database 1 1 5 stores 
a library of scoring characteristics licensed from a vender or defined by the user. 
Referring to FIG. 10, the flow of an exemplary request that includes all of the 
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features of score module 810 is shown. As described with reference to bureau 
module 805 above, the present invention provides flexibility to the user in that the 
user may create a request that includes any number of these features and in any 
order that logically makes sense. 

The flowchart in FIG. 10 begins at step 1005 with control passing 
immediately to step 1010. In step 1010, the pre-score feature is executed. The 
pre-score feature determines whether score module 8 1 0 should run based on user- 
defined criteria. A rule set is identified by front end system 1 10 or is chosen 
based on selection rules as valid for the application. Each rule in the rule set is 
evaluated by evaluator module 705. If any rule fails, scoring of the application 
is not done. A common pre-score rule would be "Applicant is NOT pre 
approved." The output of the pre-score feature is an indication of "yes" or "no." 
Control then passes to step 1015. 

In step 1015, the score profile selection feature is executed. The score 
profile selection feature utilizes a valid score profile ID that may be passed in by 
front end system 110. If the valid score profile ID is not passed in by front end 
system 1 10, a list of rule sets will be evaluated by evaluator module 705 via 
selection rules. Each rule set will have a score profile ID attached to it. The ID 
attached to the first rule set that returns "Passed all Rules" becomes the selected 
(or valid) score profile ID. The output of the score profile selection feature is the 
score profile ID. Control then passes to step 1020. 

In step 1020, the score profile feature is executed. The score profile 
feature determines which scorecard 605 is to be used for the application. Here, 
the scorecard used may be either a champion scorecard or a challenger scorecard. 
A challenger scorecard is used a percentage of the time, where the percentage of 
the time is defined by die user. The general purpose of the challenger scorecard 
is to compare its results to those of the champion scorecard to determine if it 
provides a better evaluation of credit worthiness. The output of the score profile 
feature is the scorecard ID that is to be used for the application. Control then 
passes to step 1025. 
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In step 1025, the characteristic evaluation feature is executed. This 
feature receives the valid scorecard ID that was either passed in by front end 
system 1 1 0 or determined by the score profile feature above. The characteristic 
evaluation feature evaluates each characteristic in scorecard 605 that has the valid 
ID associated with it. Characteristics may be based on bureau data or application 
data. The output of this feature is a value for each characteristic evaluated. 
Control then passes to step 1030. 

In step 1030, the attribute evaluation feature is executed. The attribute 
evaluation feature determines the weight or points that are assigned to each 
characteristic in scorecard 605. The output of this feature is an attribute (i.e. 
weight). As mentioned above, an attribute/weight is a numeric value, positive or 
negative, that is added to an overall score. Control then passes to step 1035. 

In step 1 035, the grade matrix selection feature is executed. This feature 
evaluates a list of rules to determine the grade matrix ID if the valid grade matrix 
ID is not passed in by front end system 1 10. Each rule set has a grade matrix ID 
attached to it. The ID attached to the first rule set that returns "Passed All Rules" 
becomes the selected grade matrix ID. The output of this feature is the grade 
matrix ID. Control then passes to step 1040. 

In step 1040, the grade assignment feature is executed. A grade is an 
overall indicator of an application's credit worthiness. This feature utilizes grade 
matrix data 625 associated with the grade matrix ID that was either determined 
by the grade matrix selection feature or passed in by front end system 110. 
Matrix data 625 can be both customized by the user and pre-defined by the 
present invention. Matrix data 625 is used by the present invention to compare 
one type of data to another. Table 7 below illustrates a possible grade matrix 
that compares values for a credit bureau score and values for LTV. 
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Table 7 









LTV 






BUREAU 
SCORE 


70% 




80% 


90% 


i«% 


750 


Al 


A2 


A3 


Bl 


B2 


700 


A2 


A2 


A3 


B3 


B3 


650 


A3 


A3 


A3 


B3 


C! 


600 


Bl 


Bl 


Bl 


CI 


C2 


»0 


B2 


B2 


B2 


C2 


C3 



10 The grades indicated in Table 7 are Al, A2, A3, and so forth. Al 

indicates that the applicant has the strongest credit worthiness, while C 3 indicates 
the weakest credit worthiness. The output of this feature is the grade for the 
application. For example, if the present invention determines that an application 
has a LTV of 75% and bureau data score of 750, the grade assignment feature will 

1 5 return a grade of A2. Control then passes to step 1 04 5 . 

In step 1045, the decision feature is executed. Here a decision status is 
assigned to the application based on the grade returned by the grade assignment 
feature. Valid decision statuses are Approve, Pending Approval, Pending, 
Pending Decline, and Decline. Although front end system 1 10 can interpret each 

20 status in its own way, typical interpretations are: Approve - no further analysis 

is required to approve the application; Pending Approval - the application is in 
a gray area and requires more analysis, but customization system 105 evaluation 
is generally favorable; Pending - customization system 105 is not able to make 
a determination regarding the application's credit worthiness; Pending Decline - 

25 the application is in a gray area and requires more analysis, but customization 

system 1 05 evaluation is generally unfavorable; and Decline - no further analysis 
is required to decline the application. The output of the decision feature is the 
decision status. Control then passes to step 1050. 
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Instep lOSO^eretroscorefeatureisexecuted. This feature provide the 
capability to compare an applicant's historical credit evaluation results with the 
appUcant'scurrentcre^ 

results use current user related data 630 and a current scorecard, historical credtt 
evaluation results use historical data 635. A user must define a time penod for 
theretro score (historical result,). If customization system 105 has called bureau 
^ontheapplieantinthe^^ 

115 In the event that bureau 125 information is not in database 115, 
customization system 105 makes a bureau request. Customization system 105 
then determines the retro score using the bureau data for the applicant that falls 
within the specified time period. The output of the retro score feature is the retro 
score. Control then passes to step 1055, where the flowchart in FIG. 10 ends. 

Example of Possible Score Module Requests 

The present invention provides flexibility to the user in that the user may 
create a request that includes any number of these features and in any order that 
logically makes sense. Following in Table 8 is each possible feature of score 
module 810, including a unique ID, name, and output for each feature. 



Table 8 



Pre- Score 



Sc2 



ScT 



Sc4 



Sc5 
Sc6~ 



Score Profile Selection 



Score Profile 



Scorecard ID 



Characteristic Evaluation 



Values for each Characteristic 



Attribute Evaluation 



Grade Matrix Selection 



We ight for each Characteristic, 
Grade Matrix ID 



Score 



Grade Assignment 



Grade 



Decision Application 



Decision Status 



The purpose for TableSis to illustrate possible score module 8 10 requests 
shown in Table 9. Table 9 mcludes a unique number for the request, what ts 
passed in by front end system 1 10 and supplied by other modules to score 
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module 810, and the request itself (the listing of the features of score module 810 
to execute). The requests shown in Table 9 may be both defined by the present 
invention and/or defined by the user. It is important to note that the present 
invention is not limited to the requests shown in Table 9. 



Table 9 





V/! " ; 




Score 1 


Application Data 


Scl - S8 (If no bureau characteristics 
in Scorecard) 


Score2 


Application Data, Bureau Data 
(Bu7) 


Scl - S8 


Score3 


Application Data, Bureau Data 
(Bu7), Scorecard ID 


Sc4 - Sc8 


Score4 


Application Data, Values for 
Characteristics, Scorecard ID 


Sc5 - Sc8 



Referring to Table 9 and the Score 1 request, only the application data is 
passed to score module 810. Therefore, score module must execute without any 
bureau data. Here, scorecard 605 can not be evaluated if it contains bureau 
characteristics. The request involves executing features Scl through Sc8. 

With the Score2 request, the application data and the bureau data are 
passed to score module 8 1 0. Here, scorecard 605 can be evaluated if it contains 
bureau characteristics. The Score2 request involves executing features Scl 
through Sc8. 

With the Score3 request, the application data, the bureau data, and the 
scorecard ID are passed to score module 810. Since the scorecard ID is 
provided, there is no need for features Scl through Sc3 to be executed. The 
Score3 request only executes features Sc5 through Sc8. 

Finally, with the Score4 request, the application data, the values for 
characteristics, and the scorecard ID are all passed to score module 810. Here, 
only features Sc5 through Sc8 are executed. 
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3. Price Module 



Price module 8 1 5 of the present invention determines some of the "terms" 
of the loan. Possible "terms" include a suggested interest rate, payment, deposit 
amount, and credit limit. Database 115 stores a library of pre-defined and user- 
defined matrices and tables to assist in the determination of the "terms" of the 
loan. Referring to FIG. 1 1 , the flow of an exemplary request that includes all of 
the features of price module 81 5 is shown. As described with reference to bureau 
module 805 and score module 810 above, the present invention provides 
flexibility to the user in that the user may create a request that includes any 
number of these features and in any order that logically makes sense. 

The flowchart in FIG. 11 begins at step 1105 with control passing 
immediately to step 1 1 10. In step 1 1 10, the pre-price feature is executed. The 
pre-price feature determines whether price module 81 5 should run based on usef- 
defmed priteria. A rule set is .dentified by front end system 1 10 or is chosen 
based on selection rules as valid for the application. Each rule in the rule set is 
evaluated by evaluator module 705. If any rule fails, pricing is not done. A 
common pre-price rule would be "The application is NOT automatically 
declined." The output of the pre-price feature is an indication of "yes" or "no." 

Control then passes to step 1115. 

Instep 1115, the program selection feature is executed. Aprogramisa 

way of organizing fixed rate sheets, variable rates, credit limits, and deposit 
amounts. Programs can point to arate matrix for a fixed rate, a variable rate table 
for a variable rate, or a matrix that returns a credit limit or deposit amount, all of 
which are stored in database 1 15. For example, vanable rate tables contain an 
index (such as prime rate), a margin (plus or minus), a floor, and a ceiling. 
Programs also have effective dates and expiration dates. The effective date 
indicates the first date a program may be used by the present invention, while the 
expiration date indicates the last date a program may be used. 

The program selection feature utilizes a valid program ID that may be 
passed in by front end system 1 10. If the valid program ID is not passed in by 
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front end system 1 10, a list of rule sets will be evaluated by evaluator module 
705 via selection rules. Each rule set will have a program ID attached to it. The 
ID attached to the first rule set that returns "Passed all Rules" becomes the 
selected (or valid) program ID. The output of the program selection feature is the 
program ID. Control then passes to step 1 1 20. 

In step 1120, the pricing feature is executed. The pricing feature 
determines a price for the application. This feature receives the valid program ID 
that was either passed in by front end system 1 10 or determined by the program 
selection feature above. The most common method of pricing would be returning 
a rate from a rate matrix, which is then used to calculate a payment. Table 10 
illustrates an exemplary rate matrix that compares the amount financed by the 
term. 



Table 10 



TERM 


AMOUNT 
FINANCED 


12 


24 


36 


48 


60 


25,000 


7.5 


8 


8.25 


8.5 


8.5 


20,000 


S 


8 


8.25 


7.75 


8.75 


15,000 


82.5 


8.25 


8.25 


8.75 


9 


10,000 


8.5 


8.5 


8.5 


8.75 


9 


5.000 


8.75 


8.75 


8.75 


9 


9 



The output of the pricing features may include: ( 1 ) interest rate; (2) credit 
limit; or (3) deposit amount. Control then passes to step 1 125. 

In step 1125, the rate variance selection feature is executed. A rate 
variance can be used to add or subtract from the suggested interest rate, based on 
user-defined criteria. For example, bank employees may get .25% subtracted 
from their rate. Whereas, high risk applicants may get .25% added to their rate. 
The rate selection feature utilizes a valid rate variance ID that may be passed in 
by front end system 1 10. If the valid rate variance ID is not passed in by front 
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end system 1 1 0, a list of rule sets will be evaluated by evaluate* module 705 via 
selection rules. Each rule set will have a rate variance ID attached to it. The ID 
attached to the first rule set that returns "Passed all Rules" becomes the selected 
(or valid) rate variance ID. The output of the rate variance selection feature is the 
rate variance ID. Control then passes to step 11 30. 

In step 1 130, the rate variance feature is executed. The rate variance 
feature determines the adjusted rate for the application. This feature receives the 
rate variance ID that was either passed in by front end system 1 10 or determined 
by the rate variance selection feature above. The output of the rate variance 
feature includes: (1) the rate variance; and (2) the adjusted rate. Control then 
passes to step 1135. 

In step 1 1 35, the payment calculation feature is executed. The payment 
calculation feature determines the payment for the application. The payment is 
partly based on the interest rate (either received from the pricing feature if no rate 
variance was required, or from the rate variance feature if an adjusted rate was 
required). The payment may also based on the credit limit and/or the deposit 
amount (both determined by the pricing feature). If the credit limit or deposit 
amount requires a calculation, and is not just pulled from a matrix stored in 
database 1 1 5 during the pricing feature, the calculation is done here by calculator 
module 710. The output of the payment calculation feature is the payment. 
Control then passes to step 1 140, where the flowchart in FIG. 1 1 ends. 

Example of Possible Pricing Module Requests 

The present invention provides flexibility to the user in that the user may 
create a request that includes any number of these features and in any order that 
logically makes sense. Following in Table 1 1 is each possible feature of pricing 
module 815, including a unique ID, name, and output for each feature. 
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Table 11 











Prl 


Pre-Price 


Yes or No 


Pr2 


Program Selectkm 


Program ID 


Pr3 


Pricing 


Rate, Credit Limit, or Deposit Account 


Pr4 


Rate Variance Selection 


Rate Variance ID 


PrS 


Rate Variance 


Rate Variance and Adjusted Rate 


Pr6 


Payment Calculation 


Payment _J 



The purpose for Table 11 is to illustrate possible price module 815 
requests shown in Table 1 2. Table 1 2 includes a unique number for the request, 
what is passed in by front end system 1 10 and supplied by other modules to price 
module 815, and the request itself (the listing of the features of price module 815 
to execute). The requests shown in Table 1 2 may be both defined by the present 
invention and/or defined by the user. It is important to note that the present 
invention is not limited to the requests shown in Table 12. 



Table 12 




P . ! ■ > ' : 


"prl J - Pr6 


Price 1 


Application Data 




Price2 


Application Data, Program ID (Pr2) 


Prl,Pr3-Pr6 



Referring to Table 1 2 and the Pricel request, only the application data is 
passed to price module 8 1 5. The request involves executing features Prl through 
Pr6. 

With the Price2 request, the application data and the program ID are 
passed to price module 815. Since the program ID is provided, there is no need 
for feature Pr2 to be executed. The Price2 request only executes features Prl and 
Pr3 through Pro. 

4. Policy Module 

Policy module 820 of the present invention groups rules indicating 
guidelines of a particular user (e.g., lender) that reflects its review and lending 
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policies- Ane^mpi.of.panicularbureau'sbntogpo.icym.ybe MM) 
d ec li «« W lic«io»»itb.45%D*t«..ncon«IUtio.» Referring to FIG. 12, 

820 is she™. As described wUh modules •» - 81 5 

ft. present invention provides flexibility lo the oser in that die user may create 

a r*,uest that includes any number of mese features and in en, order tat 

logically makes sense. 

The floweh-. in FIG. 12 begins m step 1205 with control passu* 
immediately roan* ,210. Insrep 1210, the pre-po.ie, feature is executed. The 
pre-policy featum defines whether policy module 820 should run based on 
user-deftned criteria. Amies* is idenrifiedb, front end system IlOoris chosen 
based on selection rules as valid for the application. E*=h rule in the rule se, .s 
evaluated by evaluato, module 705. If any rule * P»«cy modu>e 820 is no, 
executed. The output of the pre-polic, feature is an indication of "yes" or "no. 

Control then passes to step 121 5. 

.nstep illS.thecalculationselectionfeature.sexecuted. The calculate 

selection feature utilizes a valid calculation set ID that may be passed in by front 
end system 1 10. If the valid calculation set ID is not passed in by front end 
system 1 10, a list of rule sets will be evaluated by evaluator module 705 vva 
selectionru.es. Each rule set will have a calculation set ID attached ThelD 
attached to the first rule set that returns "Passed all Rules" becomes the selected 
(or valid)calculationse^ 

calculation set ID. Control then passes to step 1220. 

In step 1220, the calculations feature is executed. The calculations to be 
run by this feature may differ depending on user-defined criteria. For example 
the LTV for a vehicle product may only consider the current loan, while the LTV 
of a home equity product would typically want to consider all loans agamst the 
collateral. The present invention allows all of the applicable calculations to be 
p.aced into one set. This feature receives the calculation set ID that was either 
passed in by front end system 1 10 or determined by the calculation selects 
feature above. The output of me calculations feature includes the results of the 
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calculations (by calculator module 7 10). These results get stored in database 115 
for use in policy rules 620. Control then passes to step 1225. 

In step 1225, the review above selection feature is executed. The review 
above selection feature utilizes a valid review above rule set ID that may be 
passed in by front end system 1 10. If the valid review above rule set ID is not 
passed in by front end system 110, a list of rule sets will be evaluated by 
evaluator module 705 via selection rules. Each rule set will have a review above 
rule set ID attached to it. The ID attached to the first rule set that returns "Passed 
all Rules" becomes the selected (or valid) review above rule set ID. The output 
of the review above selection feature is the review above rule set ID. Control 
then passes to step 1230. 

In step 1230, the review above feature is executed. This feature receives 
the review above rule set ID that was either passed in by front end system 1 10 or 
determined by the review above selection feature above. Review above rules are 
included in policy rules 620. In general, a review above rule is used by this 
feature to prevent automatic approval of an application and to alert an analyst 
about problem areas in an application. A typical review above rule is "Look 
closely at an application with a 42% Debt to Income Ratio." If an application has 
an "Approve" decision status (see the decision application feature of score 
module 810) and a review above rule has been triggered, then this feature will 
change the decision status to "Pending Approval." Review above rules may also 
have codes attached to them that indicate the reason for the adverse action. This 
is useful for completely automated systems, where an analyst is not available to 
assign the reasons for the adverse action. These reasons could be listed in a letter 
to the applicant indicating that his or her application has been turned down. The 
output of this feature is the result of each review above rule. Control then passes 
to step 1235. 

In step 1235, the review below selection feature is executed. The review 
below selection feature utilizes a valid review below rule set ID that may be 
passed in by front end system 110. If the valid review below rule set ID is not 
passed in by front end system 110, a list of rule sets will be evaluated by 
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evaluator module 705 via selection rules. Each rule set will have a review below 
rule set ID attached to it. The ID attached to the first rule set that returns "Passed 
all Rules" becomes the selected (or valid) review below rule set ID. The output 
of the review below selection feature is the review below rule set ID. Control 

then passes to step 1240. 

In step 1240, the review below feature is executed. This feature receives 
the review below rule set ID that was either passed in by front end system 1 1 0 or 
determined by the review below selection feature above. Review below rules are 
included in policy rules 620. In general, a review below rule is used by this 
feature to prevent automatic declines of an application and to alert an analyst 
about circumstances inan application that warrant a closer look. Atypical review 
below rule is "Look closely at an application where the applicant make over 
$100,000 per month." Here, an analyst may want to consider approving the loan 
even if some other policy rules 620 have been violated. If an application has a 
"Decline" decision status (see the decision application feature of score module 
8 1 0) and a review below rule has been triggered, then this feature will change the 
decision status to "Pending Decline." Review below rules will only be evaluated 
by evaluator module 705 when an application has a decision status of "Decline." 
The output of this feature is the result of each review below rule. Control then 

passes to step 1245. 

In step 1 245, the policy selection feature is executed. The policy selection 
feature utilizes a valid policy rule set ID that may be passed in by front end 
system 1 10. If the valid policy rule set ID is not passed in by front end system 
110, a list of rule sets will be evaluated by evaluator module 705 via selection 
rules. Each rule set will have a policy rule set ID attached to it. The ID attached 
to the first rule set that returns 'Passed all Rules" becomes the selected (or valid) 
policy rule set ID. The outputof the policy selection feature is the policy rule set 

ID. Control then passes to step 1250. 

Instep 1250, the policy rules feature is executed. This feature receives the 
policy rule setID that was either passed in by front end system 1 1 0 or determined 
by the policy rule selection feature above. The rules used by this feature are 
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lcndmg rules and are included in policy rules 620. A lending rule is used to 
prevent users from approving loans that are outside of the company's guidelmes. 
A typical lending rule is "Definitely decline an application with a 45% Debt to 
Income Ratio." Lending rules may also have codes attached to them that 
indicates the level of the lender. Different lender levels may be used by front end 
system HO to prevent some users from violating policies, while giving other 
users the ability to override policy violations for an application. Note that policy 
module 820 may change the decision for the application based on policy rules 
620. The output of this feature is the result of each lending rule. Control then 
passes to step 1255, where the flowchart in FIG. 12 ends. 

Example of Possible Policy Module Requests 

The present invention provides flexibility to the user in that the user may 
create a request that includes any number of these features and in any order that 
logically makes sense. Following in Table 13 is each possible feature of policy 
module 820, including a unique ID, name, and output for each feature. 



Pol 
Po2 



PoT 



Po4 



Po5 



Table 13 



Pre-Policy 



Calculation Selection 
Calculations 



Review Above Selection" 



Revi ew Above 
Review Below Selection 



Yes or No 

Calculation Set lu 



Results of each Calculation saved in Uatabasc 



Review Above Rule Set 1L> 



Results of each Review rule 



Review Below Rule Set lu 




The purpose for Table 13 is to illustrate possible policy module 820 
requests shown in Table 14. Table 14 includes a unique number for the request, 
what is passed in by front end system 1 1 0 and by other modules to policy module 
820, and the request itself (the listing of the features of policy module 820 to 
execute). The requests shown in Table 14 may be both defined by the present 
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invention and/or defined by the user. It is important to note that the present 
invention is not limited to the requests shown in Table 14. 

Table 14 



Poiicyi 


Application 5ata 


l^oT - Po^ (if no Ir^nci and Review 
Rules depend on Bureau data) 


Policy 2 


Application Data, Review 
Above Rule Set ID, Review 
Below Rule Set ID 


Pol - Po3, Po5, Po7-Po9 



Referring to Table 14 and the Policy 1 request, only the application data 
is passed to policy module 820. Therefore, policy module 820 must execute 
without any bureau data. The Policy 1 request can only operate if all lending 
rules and review rules (both above and below) do not depend on bureau data. The 
request involves executing features Pol through Po9. 

With the Policy2 request, the application data, review above rule set ID, 
and the Review Below Rule Set ID are passed to policy module 820. Therefore, 
features Po4 and Po6 are not executed. The request involves executing features 
Pol through Po3, Po5, and Po7 through Po9. 

5. Product Module 



Product module 825 of the present invention is used to determine whether 
an application is qualified for multiple products. Examples of a product include 
vehicle loans, vehicle leases, home equity loans, credit cards, and so forth. For 
example, an application may be for a vehicle loan. The user may also want to 
qualify the application for a vehicle lease to give the applicant an option. Another 
example is the situation where the applicant applies for a vehicle loan, and the 
user wants to qualify him or her for a credit card and a home equity line of credit. 
The user may then attempt to cross sell the other products if the applicant 
qualifies. Referring to FIG. 13, the flow of an exemplary request that includes 
all of the features of product module 825 is shown. As described with reference 
to modules 805 - 820 above, the present invention provides flexibility to the user 
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in that the user may create a request that includes any number of these features 
and in any order that logically makes sense. 

The flowchart in FIG. 13 begins at step 1305 with control passing 
immediately tostep 1310. Instep 13 10, the pre-product feature is executed. The 
pre-product feature determines whether product module 825 should run based on 
user-defined criteria. A rule set is identified by front end system 110 or is chosen 
based on selection rules as valid for the application. Each rule in the rule set is 
evaluated by evaluator module 705. If any rule fails, product module 825 is not 
executed. The output of the pre-product feature is an indication of "yes" or "no." 
Control then passes to step 1315. 

In step 1315, the multiple product selection feature is executed. The 
multipleproductselection feature utilizes a valid multiple product rule set IDthat 
may be passed in by front end system 1 10. If the valid multiple product rule set 
ID is not passed in by front end system 1 10, a list of rule sets will be evaluated 
by evaluator module 705 via selection rules. Each rule set will have a multiple 
product set ID attached to it. The ID attached to the first rule set that returns 
"Passed all Rules" becomes the selected (or valid) multiple product rule set ID. 
The output of the this feature is the multiple product rule set ID. Control then 

passes to step 1320. 

In step 1 320, the multiple product qualification feature is executed. This 
feature reoeives the multiple product rule set ID that was either passed in by front 
end system 1 10 or determined by the multiple product selection feature above. 
For application, market analysis, and cross selling purposes, users of the present 
invention may want to run an application through multiple scorecards 605, policy 
rules (both review and lending) 620, and suggest multiple decisions. The 
additional scorecards 605, review rule sets, and policy rule sets to be run by this 
feature may be user-defined. Users may also enter via front end system 1 10 
dollar amounts and terms (when applicable) for the additional products. The 
output of this feature is a request to the initiator feature (discussed below) to 
determine if the application can qualify for additional products. Control then 
passes to step 1325, where the flowchart in FIG. 13 ends. 
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Example of Possible Product Module Requests 

The present invention provides flexibility to the user in that the user may 
create a request that includes any number of these features and in any order that 
logically makes sense. Following in Table 1 5 is each possible feature of product 
module 825, including a unique ID, name, and output for each feature. 



Table 15 



Pd2 


^re-Product 
Multiple Product 
Selection 


mmmtfM j? ; ^ ., : 

Yes or No _ 
Multiple Product Set IU 


Pd3 


Multiple Product 
Qualification 


Request Passed to Initiator 



The purpose for Table 15 is to illustrate possible product module 825 
requests shown in Table 1 6. Table 1 6 includes a unique ID for the request, what 
is passed in by front end system 110 and by other modules to product module 
825, and the request itself (the listing of the features of product module 825 to 
execute). The requests shown in Table 1 6 may be both defined by the present 
invention and/or defined by the user. It is important to note that the present 
invention is not limited to the requests shown in Table 16. 

Table 16 



R*iueitii> 








Product 1 
Product2 


Application Data 

Application Data, Multiple Product Rule Set ID 


Pdl-Pdi 
Pdl,Pd3 



is 



Referring to Table 1 6 and the Productl request, only the application data 
passed to product module 825. Therefore, product module 825 must execute 
without any bureau data. The request involves executing features Pdl through 
Pd3. 

With the Product2 request, the application data and multiple product rule 
set ID are passed to product module 825. Therefore, feature Pd2 is not executed. 
The request involves executing features Pdl and Pd3. 
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6. Examples of Possible Application Requests 

As stated above, bureau module 805, score module 810, price module 
815, policy module 820, and product module 825 can be operated independently 
of each other. This is true as long as each module has the needed data to process 
the request. The needed data to process a request may be either passed in via 
front end system 110, collected by customization system 105, or derived by 
customization system 105. 

Just as Tables 6, 9, 12, 14, and 16 illustrated possible requests for bureau 
module 805, score module 810, price module 815, policy module 820, and 
product module 825, respectively, Table 17 illustrates possible application 
requests. An application request combines one or more module request, as shown 
below. Table 17 includes a unique ID for the request, what is passed in by front 
end system 110, and the request itself (the listing of the module requests to 
execute). The requests shown in Table 17 may be both defined by the present 
invention and/or defined by the user. The present invention is not limited to the 
requests shown in Table 1 7. 



Table 17 









Appl 


Appiication Data 


Bureau 1, Score2, Price 1, Pol icy 1, 
Product 1 


App2 J 


Application Data 


Score 1, Price 1, Policy U Product 1 


App3 


Application Data, OUT 
File 


Bureau2, Score2, Price 1, Pol icy 2, 
Product 1 


App4 


Application Data, 
parsed OUT file 


Bureau3, Scorc2, Priccl, Pohcy2, 
Product 1 


App5 


Application Data, 
Values for 
Characteristics 


Score4, Pricel, Policy 1 



Referring to Table 17 and the Appl request, only the application data is 
passed in. With the Appl request, the Bureau 1 request will be executed first, 
followed by the Score2 request, followed by the Pricel request, followed by the 
Policy 1 request, and finally the Productl request will be executed. 
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The Bureaul request is executed first. Referring to Table 6, the Bureaul 
request involves executing all of the features of bureau module 805, including 
executing features Bui through Bu9 (from Table 5). Note that the Bureaul 
request also only requires the application data to be passed to it from front end 
system 110. 

The Score2 request is executed second. Referring to Table 9, the Score2 
request involves executing all of the features of score module 810, including 
executing features Scl through Sc8 (from Table 8). Note that the Score2 request 
requires that the application data be passed in by front end system 1 10 and the 
bureau data to be supplied by the feature Bu7. The feature Bu7 is executed by the 
Bureaul request and thus available for the Score2 request. 

The Price 1 request is executed third. Referring to Table 12, the Price 1 
request involves executing all of the features of price module 815, including 
executing features Prl through Pr6 (from Table 1 1). The Pricel request only 
requires the application data to be passed in by front end system 1 10. 

The Policy 1 request is executed next. Referring to Table 14, the Policy 1 
request involves executing all of the features of policy module 820, including Po 1 
through Po9 (from Table 1 3). The Policy 1 request only requires the application 
data to be passed in by front end system 1 10. 

Finally, the Product 1 request is executed. Referring to Table 16, the 
Product request involves executing all of the features of product module 825, 
including Pdl through Pd3 (from Table 15). TheProductl request only requires 
the application data to be passed in by front end system 1 10. 

The other application requests, App2 through App5, are executed in a 
similar manner as explained with reference to the Appl request above. 

C. Administration Modules 

Each module of administration modules 210 performs a unique set of 
administrative features that are also based on the specific business requirements 
defined by the user. As stated above, administration modules 210 is connected 
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to front end system 1 10 and database 115. The types of data stored in database 
11 5 are partially determined through user-defined customization via front end 
system 110. Administration modules 210 are utilized by the user to custom.ze 
system 105, perform overall management duties, to generate various reports, and 
to manipulate data stored in database 115. The reports may include a list of 
different types of data stored in database 115 (e.g., a list of the currently acUve 
rules, rule sets, characteristics, and so forth). To assist the user in the 
customization of system 105, the present invention provides a vanety of GUIs 
accessible via front end system 110. The GUIs will be briefly mentioned where 
applicable in this Section and will be described below in detail in Section VII. 

Referring to FIG. 14, administration modules 210 provides a 
rule/scorecard module 1405, a user/database module 1415, an initiator module 
1410 an object request broker (ORB) manager module 1420, and an 
administration module 1425. These modules are described for illustrative 
purposes. The invention is not limited to these modules. 

/. Administration Module 

Admimstrationmodulel425providesmefrontendformeadxmnistration 
of both the user-defined data and database 115. Administration module 1425 
allows the user to create tables and views, maintain database 115, obtain various 
reports, and administer logon activities such as logon passwords. Front end 
system 110 provides an administration GUI to facilitate the user in the 
administration of database 115. This GUI will be described in detail below in 
Section VII with reference to FIGs. 15-19. 

2. Rule/Scorecard Module 

Rule/scorecardmodule 1405provides the user the ability to create and/or 
update characteristics,calculationnaes615,scorecards605,niatrixdau62 
sets, rule set lists, pre-feature and selection rules, bureau set-up tables 640, and 
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so forth. Front end system 1 10 provides an expression builder GUI to facilitate 
the user in creating/updating characteristics, calculation rules 61 5, andpre-feature 
and selection rules. This expression builder GUI will be described in detail 
below in Section VII with reference to FIGs. 20-26. Front end system 1 10 also 
provides a rule set builder GUI to facilitate the user in creating/updating rule sets. 
This rule set builder GUI will be described in detail below with reference to 
FIG. 27. In addition, front end system 1 1 0 provides a rule list builder GUI 
to facilitate the user in creating/updating rule set lists. This rule list builder GUI 
will be described in detail below with reference to FIG. 28. Front end system 1 10 
also provides a scorecard builder GUI to facilitate the user in creating/updating 
scorecards. This scorecard builder GUI will be described with reference to 
FIGs. 29-32. Front end system 1 1 0 provides a matrix builder GUI to facilitate the 
user in creating/updating matrix 625. This matrix builder GUI will be described 
with reference to FIG. 33. 

3. Initiator Module 

Initiator module 1410 is the interface to front end system 1 10. Initiator 
module 141 0 is also responsible for coordinating, prioritizing, and arbitrating the 
activities amongst the various modules of customization system 105. Initiator 
module 1410 controls, via requests, which features of the modules of the present 
invention are executed, and in what order the features are executed. Both user- 
defined and pre-defined requests group the features. Various requests were 
described in detail above in Section VI. 

Initiator module 141 0 is also responsible for accepting application data via 
front end system 1 10, initiating the evaluation process, and returns results via 
front end system 1 10 back to the user. Front end system 1 10 provides a request 
builder GUI to facilitate the user in creating user-defined requests. This request 
builder GUI will be described in detail below in Section VII with reference to 
FIG. 34. 
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4. Object Request Broker (ORB) Manager Module 

A preferred embodiment of the present invention, as described above, is 
when the modules (and the features within) are built and packaged as CORBA 
compliant modules with CORBA IDL used for interface specifications between 
the modules. In fact, when the modules of the present invention are built and 
packaged as CORBA compliant modules, network 220 (FIG. 2) is implemented 
as anORB. Network 220 is really an 'object bus' that handles all communication 
between application processing modules 205, administration modules 210, and 
background modules 21 5. It is the implementation of the modules of the present 
invention as CORBA compliant modules that helps to provide ease of 
customization to users. It is possible to provide variations of the features through 
multiple interfaces of the modules. To the extent possible, business functionality 
is separated from technical implementation. This separation provides future 
maintainability, ease of enhancements, and additions of new features. 

The present invention provides ORB manager module 1420 to manage 
network 220 when it is implemented as an ORB. ORB manager module 1420 
provides the following functions including notification of CORBA exceptions, 
console viewing of diagnostic messages, activity viewing for ORB applications, 
activity measurement for ORB applications, shutting down specified ORB 
servers, notification of unexpected server termination, and assignment of 
properties to ORB applications. For example, properties can be used to assign 
application names and version numbers of ORB applications. 

5. User/Database Module 

User/database module 1415 provided by the present invention manages 
user access (security) and database 115 administration requirements. 
User/database module 1415 controls user access by managing user passwords 
needed to access various modules of the present invention. User access is 
controlled on both an individual level and on a group level. User/database 1415 
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also facilitates database 1 1 5 administration. This includes performing backups 
of database 1 1 5, controlling bureau calling and formatting processes, displaying 
variables relating to the environment of the present invention, displaying cron 
logs, performing miscellaneous operating system utilities, initializing database 
1 1 5 for multiple users, and controlling purging and archiving routines. 

VII. Graphical User Interface (GUI) of the Present Invention 

Front end system 1 1 0 provides the GUI to users of customization system 
1 05 . Examples of GUIs provided by the present invention include administration, 
expression builder, rule set builder, rule list builder, scorecard builder, matrix 
builder, and request builder GUIs. 



A. Administration GUI 



Front end system 1 1 0 provides an administration GUI to facilitate the user 
in the administration of database 115. The administration of database 1 15 is 
accomplished via administration module 1425. An exemplary administration 
GUI screen for allowing the user to administer database 1 1 5 is shown in FIG. 15. 
Referring to FIG. 15, the administration GUI represents some of the data stored 
in database 115. As described above, traditional databases are organized by files, 
tables, records, and fields. A field is a single piece of information; a record is one 
complete set of fields; a table is a collection of records; and a file is a collection 
of tables. The administration GUI represents the data stored in database 1 15 as 
organized by files, tables, records, and fields. 

FIG. 15 illustrates a file that contains seven (7) tables. These tables 
include an expression table 1505, a rule set table 1510, a rule list table 1515, a 
scorecard table 1520, a matrix table 1525, a request table 1530, and a log table 
1535. Note that expression table 1 505 represents characteristics, calculation rules 
615, selection rules 610, etc. Log table 1535 represents a log of various 
occurrences that happen in customization system 105. 
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In FIG. 15, expression table 1505 is highlighted. This indicates that the 
records for expression table 1505 are displayed. Some of these records include 
an APR record 1565, an AmtFinance record 1570, and an AmtFinance record 
1575. Each record has multiple fields including an ID field 1540, a description 
field 1 545, an expression field 1 550, a misc code field 1 555, and an effective date 
field 1560. In general, ID field 1540 represents a unique expression ID for the 
particular record; description field 1545 gives a description of the particular 
record, expression field 1550 is the actual expression (e.g., characteristic, 
calculation rule 61 5, etc.); misc code field 1 555 represents a code that is attached 
to a rule indicating any number of things (e.g., Lending rules may have codes 
attached to them that indicates the level of the lender); effective data field 1560 
indicates the date the particular record is active. For example, AmtFinance 
records 1570 and 1575 are exactly the same except for their effective dates. 
Record 1 570 became active on April 15, 1999. Record 1575 became active on 
April 21 , 1999. Therefore, once record 1 575 becomes active, record 1 570 is no 
longer active. 

An exemplary administration GUI screen displaying the records for rule 
set table 1510 is shown in FIG. 16. Some of these records include a Policy 
record 1625 and a ReviewAbove record 1630. Each record has multiple fields 
including an ID field 1605, a description field 1610, and an effective date field 
1615. ThesefieldsrepresentsimilardatadescribedaboveinreferencetoID field 
1540, description field 1545, and effective date field 1560, respectively. 

An exemplary administration GUI screen displaying the records for rule 
list table 1 5 1 5 is shown in FIG. 1 7. These records include a Policy record 1 720 
and a PolicyRules record 1725. Each record has multiple fields including an ID 
field 1705,adescri P tion fieldl710,and an effective date field 1715. These fields 
represent similar data described above in reference to ID field 1 540, description 
field 1545, and effective date field 1560, respectively. 

An exemplary administration GUI screen displaying the records for 
scorecard table 1 520 is shown in FIG. 18. These records include a Scorecardl 
record 1820 and a Scorecardl record 1825. Each record has multiple fields 
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15 40^ S cripdo n fl« M .545.^.ir«cUved. tt fi.ldl560. re sp« O W 

Bb ,e ,525 is shown in F.G. .9. These record, include a GmdeMarixl recced 

m ID field ,905, adescriprion field .9.0. . row variabre fie,d .9.5 a coW 
v^bre ,920, and an da,. field ,925 .Dfield .905. descn*.o» field 

,9,0. and effective data field ,925 represent similar data 
reference.o.Dfie.d ,540, description field '^-^^J""* 
^pecuvely. in genem,, ~ «** Md ,9.5 and column viable .920 are 
compared in some manner to produce the values stored in each matm. 

B. Expression Builder GUI 

Fron.endsysKmHOprovidesanexpnr.sionbuilderGU.totaciH^eme 
use, in creating/updating character**, cremation ndes 6,5. and pre-fearure 
aad lection ru,ea. TH. creottog/updaring is accomplished via rule/seorecard 
m „du,c ,405. The expression bonder GU, is used .o create/upoare m 
expression «b.e 1505 (FIG. ». An exemplary expression builder GUI screen 

is shown in FIG. 20. . 

Refemng to FIG. 20, me expression builder GUI includes five (5) tnpu. 
™„do» 5 and seven (7) expression bunding foldere. The five input windows 
Mode an expression ID inpu. window 2005. an effective dare input wmdow 
20, 0 . description input window 20, 5. a misc code input window 2020, and an 
expression input window 2025. These input windows How the user to spec* 
fcedmafoMhe records in expression file ,505 inF,G. ,5. In genera,, expressron 
1D iopu, window 2005 allows ore user ,o specify the unique ,D for the 
expression. The data entered into mis window oeeomes Ore dam shown ■» ID 
field 1540. Eff«tived»a input sviodow2010dlow,the user rosp^ifymedare 
the expression is to be active The data entered into this window becomes the 
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a. shown in effective date W > 560. «» ^ * 5 ^ 

the nse, . spec.* - descnpuon for the * «. — - - *" 

wi „dow becomes *. data shown in description W 1545. M.sc coco npn 
a„„wstheus«.o specify any con. ,h* shou,d be arched to rhe 
r^ion. The data entered into Una window becomes the da* shown - rntsc 
cod. field 1 555. Expression input window 2025 aUows Use use, ,0 create the 
^—h-H ^dauen^in.o^windowhacnmasd.oda.shown.n 

expression field 1550. 

The savan exp«».on building fo.dets of the express™ W.W 
tat Masanopc Bt or f o.da,2030,aonn^fo.das2035,,^ f «.d.202 

. expression fo,de, 2045, a .orecard fo.da, 2050. a datable «- *«. - 
actaw ^c«na,2060.B,c 1I c k in g nn a .yn»aof B « 8 afo 1 d OT .U««s»h M 

csy access to fee avaiLble bniiding e..m.n«s for the expression. 

An ax.mp.ao- =xpra SS ion bunder GUI screen Lining subfile, and a 

air- ->t Database folder 2055 includes rwo (2) 
syrnax checker is shown in HO. 21. Database 

subfi.es, an apptaMes anb.Ua 2105 and an app.addre* subfile 2"a 
App address subfi.e 21,0 has mulup.e building e.emen« - 
„pe bniiding Cement 2.15, an append,, bn.ld.ng *— 
Wnngh building dement 2130, and a city buUding eleven. 2135. 

OUI in FIG. 21 also MM.*.*— checker of the present * 
syntax checker tests the expression for synmx errors (such * syntax error 2. 25) 
^ indicates Ure error by a message (such as message 2140). 

An exemplar, express.cn bui.de, QUI screen ...usnanng *. bundtng 
Cement, of ofcraor folder 2030 is shown in TO. 22. Tne buildhtg etements o 
c^.fo.ner2030ine.ude."V.bn..ding.,^220 5 ..---bund.ngo.«n=« 

M e-buUdmgelemen,22,5,."rbu..dinge,.men,2220,a"< buddmg 
e 1 em«,2225,a-<.-hm 1 din,e 1 emen U 2230, a nda'>-bundu*e..men,2235^ 

An exempt expression builder GUI screen iUusbntrng the butldmg 
...men,, of consents folder 2035 is .hown in FIG. 23. The buUding elemenu of 
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constants folder 2035 include a "true" building element 2305 and a "false" 

building element 2310. 

An exemplary expression builder GUI screen illustrating the building 
elements of functions folder 2040 is shown in FIG. 24. The building elements of 
functions folder 2040 include an "avg" building element 2405, a "count" buildmg 
element2410,a"date"buildingelement2415,a«looku P "buildingelement2420, 

a "max" building element 2425, a "min" building element 2430, and a "sum" 

building element 2435. 

An exemplary expression builder GUI screen illustrating the building 

elements of expression folder 2045 is shown in FIG. 25. The building elements 
ofexpressionfolder2045includeanAPRbuildingelement2505,anAmtFmance 

bmldingelement2510.aBalancesbuildingelement2515,aBankruptcy buildmg 
element 2520, a BurScoreSOO building element 2525, a BurScore550 bmldmg 
element 2530, and a CBBkrpt building element 2535. 

An exemplary express^ builder GUI screen illustrating the buildmg 
elements of characteristic folder 2060 is show* in FIG. 26. The building 
elements of characteristic fo.der 2060 include a BankNatlTrades75Balance 
building clement 2605, a CharOOl bui.ding element 2610, a Char002 buildmg 
element 2615, and a Collections building element 2620. 



C. Rule Set Builder GUI 

Front end system 1 1 0 provides a rule set builder GUI to facilitate the user 
increating/updatingrmesets.™screating/updatingofrulesetsis 
viarule/scorecardmodule 1405. The rule set builder GUI is used to create/update 
records in rule set table 1510 (FIG. 16). An exemplary rule set builder GUI 

screen is shown in FIG. 27. 

Referring to FIG. 27, the rule set builder GUI includes five (5) input 
wmdowsandapossibleex P res S ionswindow2725.Possibleexpression S window 

indicates the available expressions to include in the rule set The five input 
windows include a rule set ID input window 2705, a description input window 
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27 1 0, an effective date input window 27 1 5, a misc code input window 2720, and 
an included expressions input window 2730. These input windows allow the user 
to specify the data for the records in rule set file 1510 in FIG. 16. 

In general, rule set ID input window 2705 allows the user to specify the 
unique ID for the rule set. The data entered into this window becomes the data 
shown in ID field 1605. Description input window 2710 allows the user to 
specify the description for the rule set. The data entered into this window 
becomes the data shown in description field 1610. Effective date input window 
2715 allows the user to specify the date the rule set is to be active. The data 
entered into this window becomes the data shown in effective date field 1615. 
Misc code input window 2720 allows the user to specify any codes that should 
be attached to the rule set. Included expressions input window 2730 allows the 
user to determine the expressions that make up the rule set. The way the user 
utilizes the rule set builder GUI to determine the expressions that make up the 
rule set will be described next. 

The rule set builder GUI includes three buttons to facilitate the user in 
determining the expressions to include in the rule set. These buttons include add 
button 2735, move up button 2740, and move down button 2745. The way in 
which the user adds an expression from possible expressions 2725 to included 
expressions 2730 is to highlight the desired expression in possible expressions 
2725 and click on add button 2735. This moves the desired expression from 
possible expressions 2725 to included expressions 2730. A user can manipulate 
the order of the expressions in included expressions 2730 by using move up 
button 2740 and move down button 2745. To move an expression up one, the 
user simply highlights the desired expression in included expressions 2730 and 
clicks on move up button 2740. To move an expression down one, the user 
simply highlights the desired expressions in included expressions 2730 and clicks 
on move down button 2745. 
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D. Rule List Builder GUI 

Front end system 1 1 0 provides a rule list builder GUI to facilitate the user 
in creating/updating rule set lists. This creating/updating of rule set lists is 
accomplished via rule/scorecard module 1405. The rule list builder GUI is used 
to create/update records in rule list table 1515 (FIG. 1 7). An exemplary rule list 
builder GUI screen is shown in FIG. 28. 

Referring to FIG. 28, the rule list builder GUI includes four (4) input 
windows and a possible rule sets window 2820. Possible rule set window 2820 
indicates the available rule sets to include in the rule set list. The four input 
windows include a rule list ID input window 2805, a description input window 
2810, an effective date input window 2815, and an included rule sets input 
window 2825. These input wmdows allow the user to specify the data for the 
records in rule list file 1515 in FIG. 17. 

In general, rule list ID input window 2805 allows the user to specify the 
unique ID for the rule set list. The data entered into this window becomes the 
data shown in ID field 1705. Description input window 28 10 allows the user to 
specify the description for the rule set list. The data entered into this window 
becomes the data shown in description field 1710. Effective date input window 
28 1 5 allows the user to specify the date the rule set list is to be active. The data 
entered into this window becomes the data shown in effective date field 1715. 
Included rule sets input window 2825 allows the user to determine the rule sets 
that make up the rule set list. The way the user utilizes the rule list builder GUI 
to determine the rule sets that make up the rule set list will be described next. 

As the rule set builder GUI, the rule list builder GUI includes three 
buttons to facilitate the user in determining the expressions to include in the rule 
set. These buttons include add button 2830, move up button 2835, and move 
down button 2840. The way in which the user adds a rule set to included rule sets 
2825 is to highlight the desired rule set in possible rule sets 2820 and click on add 
button 2830. This moves the. desired rule set from possible rule sets 2820 to 
included rule sets 2825. The way in which a user can manipulate the order in 
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which the rule sets are executed in included rule sets 2825 is by using move up 
button 2830 and move down button 2835. To move a rule set up one, the user 
simply highlights the desired rule set in included rule sets 2825 and clicks on 
move up button 2835. To move a rule set down one, the user simply lughhghts 
the desired rule set in included rule sets 2825 and clicks on move down button 
2840. 

E. Scorecard BuUder GUI 

Front end system 110 provides a scorecard builder GUI to facilitate the 
user in creating/updating scorecards 650. This creating/updating of scorecards 
650isaccomplishedviarule/scorecardmodule 1405. The scorecard builder GUI 
is usedto create/update records in scorecard table 1520(FIG. 18). An exemplary 
scorecard builder GUI screen is shown in FIG. 29. 

Referring to FIG. 29, the scorecard builder GUI includes seven (7) input 
windowsandanavailablecharacterisucs window2930. Available characteristics 
window 2930 indicates the available characteristics to include in scorecard 650. 
The available characteristics are located in expression folder 2045 and 

characteristic folder 2060. 

The seven input windows include a scorecard ID input window 2905, a 
description input window 2910, an effective date input window 2915, a 
challenger input window 2920, a usage input window 2925, an included 
characteristics input window 2935, and an attributes input window 2940. These 

input windows allow the user to specify the data for the records in scorecard file 

1515 in FIG. 18. 

In general, scorecard ID input window 2905 allows the user to spec.fy the 
unique ID for scorecard 650. The data entered into this window becomes the data 
shown in ID field 1805. Description input window 2910 allows the user to 
specify the description for the scorecard. The data entered into this window 
becomes the data shown in description field 1810. Effective date input window 
2915 allows the user to specify the date the scorecard is to be active. The data 
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entered into this window becomes the data shown in effective date field 1815. 
Included characteristics input window 2935 allows the user to determine the 
characteristics that make up scorecard 650. The characteristics included in the 
current scorecard are indicated by an ID 2945. Attributes input window 2940 
allows the user to define the fields for each attribute record of each characteristic. 
In general, attributes are defined as a numeric value, positive or negative, that is 
evaluated for a characteristic of a scorecard and added to an overall score. 
Attributes input window 2940 includes an operator field 2950, a value field 2955, 

and a points field 2960. 

As described above, the user may define the percentage of time the 
scorecard (i.e., champion) is used to score the application versus a challenger 
scorecard. The general purpose of the challenger scorecard is to compare its 
results to those of the champion scorecard to determine if it provides a better 
evaluation of credit worthiness. Challenger input window 2920 allows the user 
to determine which scorecard 650 will be used as the challenger. Usage input 
window 2925 allows the user to determine the percentage of time the challenger 
will be used to score the application. The way the user utilizes the scorecard 
builder GUI to determine the characteristics that make up the scorecard will be 
described next. 

As the previously described builder GUIs, the scorecard builder GUI 
includes buttons to facilitate the user in determining the characteristics (and 
attributes) to include in scorecard 650. These buttons include an add/remove 
button 2963, an add button 2965, and a remove button 2970. The way in whtch 
the user adds a characteristic from available characteristics 2930 to included 
characteristics 2935 is to highlight the desired characteristic in available 
characteristics 2930 and click on add button 2963. This moves the desired 
characteristicfromavailablecharacteristics2930toincludedcharBCteristic^ 

The way in which the user adds and removes an attribute from a characteristic is 
via add button 2965 and remove button 2970. To add an attribute, the user 
simply highlights the desired attribute to add and clicks on add button 2965. To 
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rem „v e aoa^b„ K ,U.= u S er S imp 1 yhi g h.i 8 h. S ,h e de sire <.»«nb„ tt ,o,en,ov=«.d 

clicks on remove button 2970. ^ kl ,,_ 
Anexempltuy scored builder GUI screen iUttt-ag example annbu.es 
of a d-~*» - shown in PIG. 30. Amibtnes input window 2940 includes 
„ p e„,o r f,e.d2950.va.uer 1 e 1 d2955, B .dpoin BB «.d2960.Referrin 8 .oFIG.30, 

3010 These attributes include 300, 15, 10, and 5. 

' An exemplary scorecard builder GUI screen illuswting challenger mp* 
window 2920 is show, in FIG. 31. Here, the user clicks on me a™w down and 
. M down window 3105 is displayed, lb. user men elicits on the desned 
scorecard 650 that is to be the challenger scorecard 

An exemplar scored bui.de, GUI screen Utattrfog «»*> «** 
wtad „„2925is S how„inF.G32. Here, the user clicks on me «row down a^d 
a p„n down window 3205 is displayed. The user then clicks on me destred 
number dun is to be me percentage of usage fo, the challenger scorecard. 

F. Matrix Builder GUI 

Fron.endsysKmilOprovides.mauixbuilderGUl.of.atilim.emeuser 
mere K h^ngone 0 rmoreofnm«x 6 25.T Us erenUng^o,n^ 
625 is accompli viarule/seorecani module 1405. ThemattxbudderGU. 
osed to create/update records in matrix table .525 (FIG. 19). An exempt 
matrix builder GUI screen is shown in FIG. 33. 

Refereing to FIG 33, the manix builder GUI includes eighl (8) input 
windows and an .vail* eolumn/row variable window 3390. Available 
column/rewv^.b.ewm4ow3390it»ica.esmeavm..blevanab te foraeolunm 

variableinpu. window 3320a„darowvariablemp». window 3330. Someof me 
avaiUb.ev 1 nsablesare.ocatedinexpreasionfolde,2045,.calc»l«io„foIder,m» 

database folder 2055. 

The eight input windows include a matrix ID input window 3305, a 
description inpu, window 3310, an effecdve dam input window 33 1 5, column 
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a u -n?0 a number of columns input window 3325, row 

■he records in matrix file 1 525 shown in FIG. 19. 

,„ B e»er*, m«rix ID inp- - 3305 Hows the »s« » *■ 

■ D for mariix 625 The data entered into this window beeomes the data 
unique ID for matrix ozd. 

u n in field 1905 Description input window 3310 allows tne 
shown in ID field 1905. P data entercd mt o this window 

soecifv the description for matrix 625. The data erne 

^^ri» U see t o^^ri M »^625(^. S -^y^^ 
"I el .rive. The da, entered into this wWow heco^ ** data shewn . 

3330 allows the user to specify tne row v*. _ atr : v6 25 
* » »..«. — •-■ Thew W « 1 ,eu S e IU ri toS ««m-xhu,^G U 

ou, »— - «- - - * 

» _ . - v ,i nta to include in matrix 
fining *e si-. «*» and matnx data to tn 

^eeu« OT5 355. a n^c..unu,h^o„3570.. ra no,eeo 1 u«n,buno„3^ 

aaQrow burion33S0.anda re »»verowb»rion33 8 5.T h ewa y ,nv,h,ehri,eu. 

200 u- Mi.hi the desired variable in available 

defines Ibe column variable ,s to b,ghl.ght the destred 

ee!unW»w variable wi^ow3390a„dclicxo«s« M «o 1 «m„b O «u.n3345.TTns 

:^«de S ^v^ 1 e,oce 1 ^v^b 1 e.ndov-3320.Thewa y n,^ 
I us e r def,ne S «,e ro „vari.b,ei SW bi B b,i S h,d,ede S i I edv tt ,ab 1 e m ava..ab 1 e 
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eo^row variable window 3390 aod d* on set - row budon 3350. T» 

moves d« desired variable to row viable window 3330. 

The uaer define, the size of «. « * -Hn g a number . 
^ r „fco^inpo,« i ndow33»^n um wo fro wsi„^^ow»» 

mdto c 1 «„ B o„ re si 2 cU«ob„«o„335S.™ S -«-s,» am x625«o,nc 1 ud e 
the desired number of rows and columns. 

eolunsns in ma** «. To add o, ..nova a desued coW, the - 

highl.gmsr T „^ dorre move a desired row, the user 8 unp,y 

button 3375, respecttvely. To add oi remove a „ 
high H 8 h Ktt .etow»do lid t S o n ada ro w b ut,on33 8 0ot ra novetowWnon3385, 

respectively. 

G. Request Builder GUI 

mo.eating/t^.insre^ 

mod* 1410 The request builder GUI i* used to ereate/upd.,e 
via initiator module i^iu. *m 

^ in quests table 1530 (F,G. 15, An exemplar, re^ budder OH 

screen is shown in FIG, 34. 

Refening to F.G. 34, ft. t«,ues, builder GUI ineludes fhree « 
»,am^u 1 e S de S e ri p.ionwmdo„34,5,a^afe.n^de^p.io"^ 

3420. Module, description w*dow 34,5 indices fte — moftdea ftom 
Wbie, the user - choose to urea, dte re,ues,. The* modules « ud. ^ 
« .) bureau module S05. scorn ntodule 8,0, polioy tnodu,. 
m ^e»20,=ndpHe«nrodu,e.25. Feanues description wndow 4,5 md -e 
fteavaiUblefea^sCforeachmodu^flomwrncbfteosercaucboose^er^e 

1 ^uesr. Tbese features may tndude ooe or mom of the features descnbed 
lr i „Seed„aV,.No tt ft,,w,e„.pa«^n,odu,ei„modu 1 edesenp«»n 

1Z. 34,5 is highlighted, a>, of the »vai,ab,e feurures for that highhghred 
module are automatically displayed in feature deseription wmdow. 
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i a- » ™.nuest ID input window 3405, a 
The three input windows include a request iu m P 

mo.ude a modu.« f,e.d 343C a M» «- 3435, and . W «* ^ 

' 52 , S „ e enem., ID *« — « *° 5 — «" ~ *° T 

sp eeify tbe description for the request. Modtde descrtptton «-*» MIS and 
specify rn P determine the WW °f 

feature description window 3420 allows xnc ua 

feature de -filtae.1lhe request burlder 

modules that make up lire request, roe ™jr - h 
OU- to determine toe feaunes of modu.es rha, m-tc up the request «... be 

"tques. WO OU. inCudes four bu«ms « «— - - * 
de™ dte feauncs of modu.es tna, mate up .be request m request rnpur 
wi „do» 3425. Tn.se buttons .nc.ude add button 3445, remove 3** 
m„veupbu«on3455,andmoved„».but Kn 3460.Tbe™».n^.ch^ 

Is a Led fearure of a modu,e from m„du,e description £ 

mTbe nt -* — - As 

modme are automaucaUy d.sp.ayed .„ feature description wmdoo, 34^ ** 
me user bighngbts tine desired feaurre in feature desenptton «*. 3** 
Finally, the user simp., «*. on add bunco 3445 to add the feanne (of*. 

module} to the request. 

Toe user removes a desited featu* (of a modu,e) from the request by 
hig mi^ngu«^-rec^m^n^window3425^eHcaO„^ 

love bunon 3450. T3te order - «bieb the features „ — - 
th eea 1 fe.tumofbur«aumodu.e 8 05wi..beexeeu K dfns,.fo..o W edbyu M score 



CA 02312641 2000-06-23 



10 



72- 

feature up one, the user 



^ndule 810 and so forth. To move a tearur* u H 

feature of score module a" u ^K«ttrtn^4S5 To 



move a feature down one, the user 
on move down button 3460. 



VIII. Conclusion 



. „»ro that may be later developed. Thus, tne 

„„j within the relevant art(s) mat may ^ 

and terms witht t hp Umued by any of the above-described exemplary 

rii::;— :r,-:— - 



and their equivalents. 
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Whot Is Claimed Is: 

1. A system for evaluating credit worthiness of an application based on user- 

defined customization, comprising: 

acustomizationdatabasehavingstored therein dataforevaluating 

credit worthiness, wherein said database data includes at least one rule; 

a customization system, wherein said customization system 
executes a request for evaluating credit worthiness of the application by 

using said rule; and 

a front end system, wherein said front end system includes means 
for allowing the user to customize said database data and access said 
customization system. 

2. The system of claim 1, wherein said database data is either passed in via 
said front end system, collected by said customization system, or derived 
by said customization system. 

3 . The system of claim 1 , wherein said front end system is a web server. 

4. The system of claim 1, wherein the application is a consumer or a 
business application. 



5. 



The system of claim I, wherein said rule is in one of the following 



categories: 

pre-feature, 

selection, 

policy, 

scorecard, and 
calculation. 

6. The system of claim I, wherein said means for allowing the user to 
customize said database data comprises an expression builder graphical 
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user interface, wherein said expression builder graphical user interface 
facilitates the user in creating and updating said rules. 

The system of claim 1. wherein said means for allowing the user to 
customize said database data comprises a rule set builder graphical user 
interface, wherein said rule set builder graphical user interface facilitates 
the user in creating and updating a rule set, wherein said rule set is a 
collection of said rules. 

The system of claim 7, wherein said means for allowing the user to 
customize said database data comprises a rule list builder graphical user 
interface, wherein said rule list builder graphical user interface facilitates 
the user in creating and updating a rule set list, wherein said rule set.sa 
collection of said rule sets. 

9 The system of claim 1, wherein said means for allowing the user to 
customizcsaiddatabasedataw 

interface, wherein said scorecard builder graphical user interface 
facilitates the user in creating and updating a scorecard, wherein said 
scorecard is a category of said rules. 

10. The system of claim I, wherein said means for allowing the user to 
customize said database data comprises a matrix builder graphical user 
interface, wherein said matrix builder graphical user interface facilitates 
the user in creating and updating a matrix. 

U. The system of claim 1, wherein said means for allowing the user to 
customize said database data comprises a request builder graphical user 
interface, wherein said request builder graphical user interface facilitates 
the user in creating and updating said request. 
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The system of claim 1. wherein said customization system comprises: 
applicationprocessmgmodulesforprovidmgpiocessingfeatuies; 
admimstxationmodulesforinterfacingwimsaiddatabaseandsaid 

front end system; and 

background modules for performing background functions 
required by said application processing modules and said administration 
modules. 

J. The system of claim 12, wherein said application processing modules 
comprise: 

a bureau module for obtaining and evaluating credit bureau data 

for the application; 

a score module for determining a score for the application using 
a scorecard, for detennining a grade for the application based on said 
score, and for determining a decision for the application based on said 
grade; 

a price module for detennining possible loan terms for the 
application based on said grade; 

a policy module for reviewing the application based on a policy 
rule, wherein said policy module may change said decision based on said 
policy rule; and 

a product module for determining whether the application is 
eligible for multiple products. 

14. The system of claim 13, wherein said bureau module, said score module, 
said price module, said policy module, and said product module have a 
pre-bureau feature, a pre-score feature, a pre-price feature, a pre-policy 
feature, and a pre-product feature, respectively, for determining whether 
to execute its respective said module. 
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15. The system of claim 13, wherein said loan terms include a suggested 
interest rate, a payment, a deposit amount, and a credit limit. 

16. The system of claim 13, wherein said products include vehicle loans, 
vehicle leases, home equity loans, and credit cards. 

17. The system of claim 12, wherein said administration modules, comprise 

a rules/scorecard module for creating and modifying said rules; 

a user/database module for managing the security of said 
customization system and administration of said database; 

an administration module for providing an administration 
graphical user interface to said database; and 

an initiator module for executing said request. 

1 8. The system of claim 17, wherein said administration modules further 
comprise an object request broker manager module. 

19. The system of claim 12, wherein said background modules comprise: 

an evaluator module for evaluating said rules; 
a calculator module for performing mathematical calculations 
requested by said evaluator module when evaluating said rules; 

a data manager module for handling interactions with said 

database data; and 

an external data parser module for accepting input data in various 
formats, parsing said input data, and saving said input data in said 
database. 

20. The system of claim 1 9, wherein said formats include fixed length and 
comma delimited. 
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A method for evaluating credit worthiness of an application based on 
user-defined customization, comprising the steps of: 

setting up a customization database, said database having stored 
therein data for evaluating credit worthiness, wherein said database data 
includes at least one rule; 

evaluating, with a customization system, the credit worthiness of 
the application by executing a request, wherein said request includes said 
rule; 

allowing the user to customize said database data through a front 

end system; and 

allowing the user to access said customization system through said 

front end system. 

The method of claim 21 , wherein said database data is either passed in via 
said front end system, collected by said customization system, or derived 
by said customization system. 

The method of claim 2 1 , wherein said front end system is a web server. 

The method of claim 21, wherein the application is a consumer or a 
business application. 

The method of claim 21, wherein said rale is in one of the following 
categories: 

pre-feature, 

selection, 

policy, 

scorecard, and 
calculation. 
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The method of claim 21, wherein said step of allowing the user to 
customize comprises the steps of: 

providing an expression builder graphical user interface; 

allowing the user to create said rules via said expression builder 
graphical user interface; and 

allowing the user to update said rules via said expression builder 

graphical user interface. 

The method of claim 21, wherein said step of allowing the user to 
customize comprises the steps of: 

providing a rule set builder graphical user interface; 

allowing the user to create a rule set via said rule set builder 
graphical user interface, wherein said rule set is a collection of said rules; 
and 

allowing the user to update said rule set via said rule set builder 
graphical user interface. 

The method of claim 27, wherein said step of allowing the user to 
customize comprises the steps of: 

providing a rule list builder graphical user interface; 

allowing the user to create a rule set list via said rule list builder 
graphical user interface, wherein said rule set list is a collection of said 
rule sets; and 

allowing the user to update said rule set list via said rule list 
builder graphical user interface. 

The method of claim 21, wherein said step of allowing the user to 
customize comprises the steps of: 

providing a scorecard builder graphical user interface; 
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allowing the user to create a scorecard via said scorecard builder 
graphical user interface, wherein said scorecard is a category of said rules; 
and 

allowing the user to update said scorecard via said scorecard 
builder graphical user interface. 

The method of claim 21, wherein said step of allowing the user to 
customize comprises the steps of: 

providing a matrix builder graphical user interface; 

allowing the user to create a matrix via said matrix builder 
graphical user interface; and 

allowing the user to update said matrix via said matrix builder 
graphical user interface. 

The method of claim 21, wherein said step of allowing the user to 
customize comprises the steps of: 

providing a request builder graphical user interface; 

allowing the user to create said request via said request builder 
graphical user interface; and 

allowing the user to update said request via said request builder 

graphical user interface. 

The method of claim 21, wherein said step of evaluating comprises the 

steps of: 

providing processing features; 

interfacing with said database and said front end system; and 
performing background functions required by said providing step 
and said interfacing step. 

The method of claim 32, wherein said providing step comprises the steps 
of: 

obtaining credit bureau data for the application; 
evaluating said credit bureau data; 
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determining a score for the application using a scorecard; 
determining a grade for the application based on said score; 
determining a decision for the application based on said grade; 
determining possible loan terms for the application based on said 

grade; 

reviewing the application based on a policy rule; 

detenmning whether to change said decision based onsaid policy 

rule; and 

determining whether the application is eligible for multiple 
products. 

The method of claim 33, wherein said loan terms include a suggested 
interest rate, a payment, a deposit amount, and a credit limit. 

The method of claim 33, wherein said products include vehicle loans, 
vehicle leases, home equity loans, and credit cards. 

The method of claim 32, wherein said interfacing step comprises the steps 

of: 

creating said rules; 
modifying said rules; 

managing the security of said customization system; 

managing the administration of said database; 

providing an administration graphical user interface to said 

database; and 

executing said request. 

The method of claim 32, wherein said performing step comprises the 

steps of: 

evaluating said rules; 
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performingnmthenmtical calculations requested by saidevaluating 

step; 

handling interactions with said database data; 
accepting input data in various formats; 
parsing said input data; and 
saving said input data in said database. 



The method of claim 37, wherein said formats include fixed length 
comma delimited. 
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